Skip to content

Instantly share code, notes, and snippets.

@annevk
Last active December 18, 2019 01:30
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save annevk/ee8c65101db5ec6b107a313272865480 to your computer and use it in GitHub Desktop.
Save annevk/ee8c65101db5ec6b107a313272865480 to your computer and use it in GitHub Desktop.
TransparentContainer nodes

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().

@annevk
Copy link
Author

annevk commented Nov 3, 2017

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 with TransparentContainer 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 and TransparentContainerEnd 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 as TransparentContainer, but it's a little less clean.

@annevk
Copy link
Author

annevk commented Nov 7, 2017

For instance, when you construct TransparentContainerStart it has an internal pointer to TransparentContainerEnd and vice versa (also exposed through .end and .start). When you insert TransparentContainerStart it inserts TransparentContainerEnd as the next sibling. When you remove TransparentContainerStart it also removes the corresponding TransparentContainerEnd. When you remove TransparentContainerEnd it throws.

TransparentContainerStart exposes all the operations to mutate the content between TransparentContainerStart and TransparentContainerEnd, such as textContent and innerHTML.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment