You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Per the separation of concerns principle, the markup should only specify semantics. Polluting it with template children when the purpose is purely stylistic goes very much against it, is inelegant, verbose, and hurts readability. And, as the blog post mentions, suffers from lack of reusability. It would be better to be able to define templates out of band (e.g. inside head or in a different resource altogether) and reference them using CSS. I.e. bring back the binding property from XBL. And events for attaching and detaching, for situations in which the author wishes to go beyond declarativity and resort to scripting.
The text was updated successfully, but these errors were encountered:
Thanks for the comment. Remember that the purpose of declarative shadow dom is to allow shadow trees of all kinds to be represented in HTML, not just the ones used for “purely stylistic” reasons. For example when serializing custom elements that use shadow dom. I’m not sure re-structuring the DOM tree via CSS is a great idea - are there any other such precedents?
Per the separation of concerns principle, the markup should only specify semantics. Polluting it with
template
children when the purpose is purely stylistic goes very much against it, is inelegant, verbose, and hurts readability. And, as the blog post mentions, suffers from lack of reusability. It would be better to be able to define templates out of band (e.g. insidehead
or in a different resource altogether) and reference them using CSS. I.e. bring back thebinding
property from XBL. And events for attaching and detaching, for situations in which the author wishes to go beyond declarativity and resort to scripting.The text was updated successfully, but these errors were encountered: