[css-nesting] concat and custom elements example/reasoning

[bkardell]

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.-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?

[tabatkins]

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.

[tabatkins]

Slightly edited the note to use an example that is a valid custom element name, and slightly generalize the text as well.