Not a bug, more an observation from a new user:
When inspecting the dom created with lit-html it is bloated with empty comment tags.
This reduces the number of "real" nodes that I can see on the screen and leads to unexpected results when selecting nodes (nextSibling may return a comment tag instead of the expected node).
As far as I understand these tags are required internally by lit-html to remember the position of dynamic nodes. Is there no better way to achieve the same result without flooding the dom (like using indexes)?
The comment nodes are required to mark the delimiters of dynamic content. Whenever you use ${ escapes } lit-html inserts these comment nodes so the dynamic part has a fixed context where it can render. With the current architecture these nodes are necessary.
The good news is that almost all of these comment nodes are static, so they are mostly generated once and not on every render. Additionally, comment nodes are extremely cheap, and have almost no cost/overhead compared to regular nodes.
In general, traversing dom nodes using nextSibling and such is not something you have to do when using a rendering engine like lit-html, since you are not supposed to manipulate rendered DOM directly. May I ask what your use case is specifically?
I've noticed the comment tags when implementing keyboard navigation for my tree component. I wanted to select the next sibling on key up / down and selected a comment tag instead of the expected element.
No big deal, just wanted to give you some feedback on the user experience.
Would be nice to have an option in the chrome inspector to hide empty comments in shadowDom.
This is working as intended. If we get the Template Instantiation proposal implemented, we'll be able to more away from comment nodes.
Most helpful comment
The comment nodes are required to mark the delimiters of dynamic content. Whenever you use
${ escapes }lit-html inserts these comment nodes so the dynamic part has a fixed context where it can render. With the current architecture these nodes are necessary.The good news is that almost all of these comment nodes are static, so they are mostly generated once and not on every render. Additionally, comment nodes are extremely cheap, and have almost no cost/overhead compared to regular nodes.
In general, traversing dom nodes using nextSibling and such is not something you have to do when using a rendering engine like lit-html, since you are not supposed to manipulate rendered DOM directly. May I ask what your use case is specifically?