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 withTransparentContainerchildren 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.,
TransparentContainerStartandTransparentContainerEndnodes 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.