A TransparentContainer
node is an object intended to be used as a primitive in templating systems. It's effectively a DocumentFragment
node that is not "unwrapped" upon insertion. TransparentContainer
nodes can be arbitrarily nested.
Selector matching and rendering will act as if any TransparentContainer
nodes in the node tree are replaced by their contents.
Hierarchy restrictions placed upon nodes will need to apply to the children of TransparentContainer
nodes as if the TransparentContainer
node was not there. We can simplify these requirements somewhat by only allowing TransparentContainer
nodes as descendants of the root element.
[Constructor,
Exposed=Window]
interface TransparentContainer : Node {
};
A TransparentContainer
node can be created using new TransparentContainer()
.
The main problem with this proposal as it stands is that it would break dependencies of the DOM, such as HTML.
<select>
should still work, even withTransparentContainer
children that contain one or more<option>
elements.That basically means you end up with new traversal APIs and quite a bit of complexity.
An alternative would be to have paired marker nodes that do not affect the depth of the tree. E.g.,
TransparentContainerStart
andTransparentContainerEnd
nodes with some requirement that they need to be linked somehow, have the same parent, and end comes after start. They could have special API that enables similar use cases asTransparentContainer
, but it's a little less clean.