-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unpredictable availability of template's content #4566
Comments
No, I don't think so. The intention is you need to react to any children changes, including any changes to the contents of your template child.
Correct. You need to never assume that there is a last mutation; you need to react to all mutations. |
In the meeting a point was brought up that you could not necessarily rely on a marker inserted after |
I'd argue that such a change is rather rare. A lot of scripts mutate the document tree in order to load resources, add iframe, etc... but not template's content tree. |
Yeah, it is rare (or close to non-existent, perhaps), but is that a sound enough principle to add new primitives for? It also creates rather different semantics for the top-most template versus any nested templates. It gives a decent workaround, but not something I'd necessarily want to commit to for the next two decades. |
We have I think scripts can currently workaround this by waiting for |
Well, but again, for any nested |
As already discussed at web-platform-tests/wpt#15487 (comment) authors have no mean to observe whether the
.content
of a<template>
was already parsed and the template is ready to be used.That makes it impossible to create a custom element, autonomous
<my-element><template>foo</template></my-element>
or customized built-in<template is="my-template">foo</template>
, which uses its template content when connected.If the template's content is streamed, then on
my-element
'sconnectedCallback
it's empty. As an author, I can attachMutationObserver
to.content
, but I never know which mutation is the last one, for a given connect. I understand that custom elements should not assume their children presence. However, I thought that's what makes<template>
element special. It does not havechildren
, it hascontent
to be used/stamped. And it does not feel intuitive to stamp something that's not finished yet.I found that the only way to use template is to be assured by other means that my code is executed after the template's content was parsed, like:
So if I want
<my-element>
to use a template I should rather use sibling relation<template>foo</template><my-element></my-element>
, not the sol or parent-children relation. I believe that is contrary to the intent behind custom elements.The concrete use-case behind my problems is implementing custom element for declarative Shadow DOM (whatwg/dom#510) that works in run-time. To make use of the fact that the needed, problematic end tag macro is already implemented for
<template>
.The text was updated successfully, but these errors were encountered: