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
In the nesting draft, section 2.1 Direct Nesting provides both rationale and examples about why things work how they do. In this is states:
__bar, for example, is a valid custom element name in HTML.
It links to the HTML spec (it is a general link, but here is the relevant anchor part). But, that isn't a valid custom element name, as the link shows (you can also verify in devtools if you find it hard to read those productions customElements.define("__foo", class Foo extends HTMLElement {}) throws with ""__foo" is not a valid custom element name".
I think what this means to say is simply -- rather than __, and indeed the BEM site has examples like .block--mod. It's temping to just log that this is probably a typo, but... is that the only issue? I'm not sure...
A single dash in custom element names is kind of the norm, and incredibly common in css selectors, even if you don't use BEM or something... That's a good example here, I guess. But while the double dash example 'holds up', it is really obscure - I'm pretty sure most people don't even know that is a valid custom element name (there are certainly very few -- tens -- in the whole HTTPArchive, and they could be serialization/parsing errors on a common tool, and not even custom elements). So, that's got me thinking whether there are any other valid custom element names that might foul something up for selectors here and... maybe there is? In reading the draft, I think we're trying to avoid here is concat'ing strings that might wind up be a tag name, and keep it to strictly selectors -- but a.-foois a valid custom element name, and would mean something different for a selector... Does this create an issues? It seems like even if it isn't, that one might be worth a note or example?
The text was updated successfully, but these errors were encountered:
Hm, not sure why I thought __bar was a valid element name. Maybe it is in XML? Or maybe I'm just wrong. <--bar> also isn't valid, as far as I know - at least when I test it, it parses as text rather than a start tag.
but a.-foo is a valid custom element name
That's fine, you can theoretically do all sorts of weird stuff that conflicts with selector syntax; you just have to escape the problematic characters to actually select them. a\2e -foo is how you'd spell that element name in a selector.
The problem overall, tho, isn't whether HTML's rules for element names allow or disallow certain patterns; it's that any such rule we'd make for telling "type selector" apart from "concatenation to parent selector" will be heuristic and thus fallible. It can easily fail in HTML itself (see foo__ { &bar {color: red;}}), and since CSS and selectors are theoretically usable more widely than HTML, it can fail in exotic and new ways in other host languages too.
In the nesting draft, section 2.1 Direct Nesting provides both rationale and examples about why things work how they do. In this is states:
It links to the HTML spec (it is a general link, but here is the relevant anchor part). But, that isn't a valid custom element name, as the link shows (you can also verify in devtools if you find it hard to read those productions
customElements.define("__foo", class Foo extends HTMLElement {})
throws with ""__foo" is not a valid custom element name".I think what this means to say is simply
--
rather than__
, and indeed the BEM site has examples like.block--mod
. It's temping to just log that this is probably a typo, but... is that the only issue? I'm not sure...A single dash in custom element names is kind of the norm, and incredibly common in css selectors, even if you don't use BEM or something... That's a good example here, I guess. But while the double dash example 'holds up', it is really obscure - I'm pretty sure most people don't even know that is a valid custom element name (there are certainly very few -- tens -- in the whole HTTPArchive, and they could be serialization/parsing errors on a common tool, and not even custom elements). So, that's got me thinking whether there are any other valid custom element names that might foul something up for selectors here and... maybe there is? In reading the draft, I think we're trying to avoid here is concat'ing strings that might wind up be a tag name, and keep it to strictly selectors -- but
a.-foo
is a valid custom element name, and would mean something different for a selector... Does this create an issues? It seems like even if it isn't, that one might be worth a note or example?The text was updated successfully, but these errors were encountered: