-
Notifications
You must be signed in to change notification settings - Fork 376
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
:unresolved vs :not(:upgraded) #418
Comments
I'm also fine with an alternative approach in which we replace every instance of the term "upgrade" to "resolve" in the spec if we think the term "resolved" is more descriptive than the term "upgrade". |
Another reasonable solution seems to be just changing it to |
Until they're upgraded, the elements are of type HTMLUnknownElement, so how about That describes their current state using existing terminology, avoids use of It also has the benefit of not presuming that the unknown element is going to be upgraded using the Custom Elements API. There are JS frameworks that make use of non-standard tags, and they could use |
This isn't true actually. Second paragraph of https://w3c.github.io/webcomponents/spec/custom/#registering-custom-elements. It's HTMLElement. |
Ah, my bad, I'd been thrown off my experience with the v0 implementation in Blink. Of the choices already listed, then, I'd prefer |
One thing I realized is that using "upgraded" might not be the best idea given that some elements (those created by the parser and by createElement) never need to be upgraded. They just start out with the right class. So maybe "resolved" = "upgraded" or "created with the right class in the first place". What this really means is that I will tentatively work from the conclusion that I should spec the concept of "resolved" to mean "upgraded" or "created with the right class in the first place" and spec that tomorrow. We'd keep |
How about |
|
@annevk : in theory, between when |
I went with Now that we have a precise defined flag, I think there is less of a timing difference than you might imagine. I don't set the flag until after the constructor is completely finished running. |
Great. I uploaded a WebKit patch with tests on https://bugs.webkit.org/show_bug.cgi?id=155108. Please check to see if that matches your expectation. |
Per WICG/webcomponents#418, the current name for this pseudo-class is `:defined`.
The template's document doesn't have a browsing context, so custom elements aren't upgraded. This change defers upgrading any custom elements inside the template until after the treewalker that links the Parts to the DOM. This is important because custom elements can modify their DOM at upgrade time (e.g. when using ShadyDOM). Fixes #231
Timing issues are still a problem. This works well: <my-el id="el"></my-el>
<script>
const defined = el.matches(':defined')
// This code needs to do something once the element is defined.
if (defined) {
console.log('el is defined')
} else {
console.log('el not yet defined')
customElements.whenDefined(el.tagName.toLowerCase()).then(() => {
console.log('el is defined? ', el.matches(':defined'))
// ^ ------------------------------------------------------------------- true (GOOD)
})
}
</script>
<!-- Definition happens sometime later: -->
<script>
customElements.define('my-el', class extends HTMLElement {
constructor() {
super()
console.log('my-el constructor')
}
connectedCallback() {
console.log('my-el connected')
}
})
</script> But this does not work: <script>
const el = document.createElement('my-el')
const defined = el.matches(':defined')
// This code needs to do something once the element is defined (upgraded).
if (defined) {
console.log('el is defined')
} else {
console.log('el not yet defined')
customElements.whenDefined(el.tagName.toLowerCase()).then(() => {
console.log('el is defined? ', el.matches(':defined'))
// ^ ----------------------------------------------------------------- false (BAD)
})
}
</script>
<!-- Definition happens sometime later: -->
<script>
customElements.define('my-el', class extends HTMLElement {
constructor() {
super()
console.log('my-el constructor')
}
connectedCallback() {
console.log('my-el connected')
}
})
</script>
<!-- The element is appended sometime later: -->
<script>
document.body.append(el)
</script> I think there should be a better solution to this. Some possible solutions:
(cc @justinfagnani as you've discussed these sorts of issues in other topics too) |
It seems odd that the custom elements API and spec refers to upgrading custom elements and yet the CSS pseudo class that corresponds to a custom element not being upgraded is called
:unresolved
.unresolved
doesn't tell us what hasn't been resolved and inconsistent with the rest of the spec / API terminology we're using.Perhaps we should consider negating it to
:upgraded
and use:not(:upgraded)
for this use case for consistency. I do admit the the latter form is a bit more verbose but I think consistency in the terminology is very valuable here.The text was updated successfully, but these errors were encountered: