Add footnote about CSS Nesting requiring a symbol to nest element selectors (in some browsers)

[jensimmons]

Adding a footnote to mark which browsers do not support nesting type selectors without a & (or other mitigation so that the selector starts with a symbol).

Firefox did not ship with this limitation.

Everyone else who supports Nesting has this limitation, except for Safari Technology Preview 179.

[jensimmons]

While marking Chromium and WebKit browsers as requiring a symbol to nest element selectors, I left those browsers as having full support (bright green box).

They do not have incomplete support. They still support all of Nesting. They just have this one requirement regarding a detail in the syntax. A requirement that was in the CSS specification, but has since been relaxed.

[Serator]

https://bugs.chromium.org/p/chromium/issues/detail?id=1427259 - Chrome (Chromium based) bug for this issue.
If Chrome is the only browser that doesn't even ship this feature in the alpha version yet, it would probably be appropriate to add this to the notes. Thanks!

[jensimmons]

Good idea. Thanks. Done.

[jensimmons]

I’d love it if this PR could be accepted by Thursday morning. :D

[Fyrd]

Thanks!

[romainmenke]

The older versions really should be marked as partial implementations.
They literally do not support the entire feature.

It is critical for users of caniuse that the data is correct.
What the specification was at a given point in time when browsers initially shipped something is irrelevant.

[brandonmcconnell]

If I understand correctly, the latest accepted implementation of this feature does not require starting with a symbol but can include a symbol anywhere. If the selector is invalid, it is then checked for a symbol.

Related— the latest comments here: w3c/csswg-drafts#8253

Is that different from what is being described here in this issue (#6840)

Are there any browsers that do not implement nesting using this behavior?

cc @tabatkins @Loirooriol

[romainmenke]

Maybe best not to start a longer conversation in a merged pull request :)

My comment was specifically to address that adding notes about partial implementations without assigning the correct status flag is a bad pattern.

[jensimmons]

I believe marking bright green with a footnote is the correct level of information.

This is not AreTheBrowserEngineersDone.com or DoesThisMatchTheStandard.com. It's CanIUse.com.

What matters is the experience of the web developer. Can they use CSS Nesting? Yes. Well, if you set aside percentage of users on which version of which browser...

If development team is building a site, and somehow magically they know 100% of their users are on Chrome 117 or Safari 17.0 — can they feel confident about using CSS Nesting? Is it solid? Trustworthy? Will it work? Yes, yes, and yes.

They do need to know about the requirement to start with a symbol when nesting an element selector. That's very important, and worthy of a prominent note. But as long as they stick to that, they are fine. Nesting is ready to be used.

Partial support conveys "hey, maybe don't use this. It's only half built. You might be able to get away with it, but there's a good chance your code will fail. Or something unstable might happen in the future. Be wary. Hold off." And I do not believe that is the correct message to send about Nesting.

Can you use CSS Nesting? Absolutely. (Once all the Chromium mobile browsers have caught up, and enough of your users have updated.) Go for it. Green boxes all the way down. This is solid and ready.

[romainmenke]

They do need to know about the requirement to start with a symbol when nesting an element selector. That's very important, and worthy of a prominent note. But as long as they stick to that, they are fine. Nesting is ready to be used.

That is the definition of "partial support" @jensimmons 😕
A feature that can be used as long as you know which parts are safe to use.

That is problematic.
We need accurate data of when a feature was fully supported.

It should really be better defined what full and partial support mean. @Fyrd?

[romainmenke]

Can it be added as a separate feature or a sub feature?

Then nesting can be what initially shipped and can remain "full supported".

That would give us green boxes now and accurate (machine readable) data.

Also important to keep in mind that the partial support status is temporary.

[brandonmcconnell]

@romainmenke @jensimmons Agreed. I was speaking to the support for div& which would work identically to &:is(div). Perhaps that's best suited for an interop issue for Interop 2024.

See related notes here: w3c/csswg-drafts#8253

---

That said, it may help to include a note/point for that capability (div&) in caniuse as well.

[Fyrd]

Yeah determining when support is partial is tricky. Originally I was more liberal in applying the "supported" label as long as the main purpose was fulfilled. By that logic this would certainly qualify as supported.

However over time developers have generally expressed a preference for "supported" meaning they can just use it without any concern at all, and "partial" whenever that's not the case. Admittedly it's much easier to see a bunch of green boxes and in this case assume the latest syntax can safely be used without reading the fine print.

The partial indicator is much harder to miss and (hopefully) does a better job encouraging people to learn about the reasoning then use their own judgment on whether or not the feature can be used. I haven't personally heard of anyone that's avoided using a feature outright due to "partial" support so I don't think that would scare anyone away.

I still don't think "supported" means the feature needs to be 100% supported as uncommon edge cases may be a reason for a note instead of partial support. But I don't think that's the case here, so I support using "partial" when a symbol is required for nested features.