The number of Internals API becomes too much API. These API should be reassigned into multiple smaller objects. My current plan is to introduce: - SettingsInternals - ElementInternals - NodeInternals - DocumentInternals
Is the plan to arrange them like: internals.settings.m() internals.element.n() etc.? I think this is neat, because existing if (window.internals) tests work, and you can slowly migrate API from internals to internals.x. Why not keep all of the DOM-related ones together, eg instead of internals.element, internals.node and internals.document just have internals.dom? It’s shorter and even if the API of internals.dom is large, it is pretty strongly related. Need to think less which specific part of internals I need for a given testing task.
(In reply to comment #1) > Why not keep all of the DOM-related ones together, eg instead of internals.element, internals.node and internals.document just have internals.dom? It’s shorter and even if the API of internals.dom is large, it is pretty strongly related. Need to think less which specific part of internals I need for a given testing task. Well. window.internals.dom might be better. What I thought is internals.element(x).foo(). But per element instance is possibly too much.
(In reply to comment #2) > (In reply to comment #1) > > Why not keep all of the DOM-related ones together, eg instead of internals.element, internals.node and internals.document just have internals.dom? It’s shorter and even if the API of internals.dom is large, it is pretty strongly related. Need to think less which specific part of internals I need for a given testing task. > > Well. window.internals.dom might be better. > What I thought is internals.element(x).foo(). Wrappers! Could be convenient. > But per element instance is possibly too much. I think per-instance is OK. I was worried if you have Node and Element I am going to need to keep track of which wrapper has the API I want. (Unless Element is a superset of Node API?) Looking at the internals API it looks like it splits into Document and Element, and there is no node. So maybe it is OK.
(In reply to comment #2) > (In reply to comment #1) > > Why not keep all of the DOM-related ones together, eg instead of internals.element, internals.node and internals.document just have internals.dom? It’s shorter and even if the API of internals.dom is large, it is pretty strongly related. Need to think less which specific part of internals I need for a given testing task. > > Well. window.internals.dom might be better. > What I thought is internals.element(x).foo(). Hm... I'm worried that this would make the test code less obvious. e.g. you can do something like: var x = internals.element(x); ... x.foo(); // Wait, where did foo come from?