[csswg-drafts] [css-nesting-1] Clearer definition of “nest-containing” (#7972)

sesse has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-nesting-1] Clearer definition of “nest-containing” ==
The spec currently reads: “If a selector in the [<relative-selector-list>](https://csswg.sesse.net/selectors-4/#typedef-relative-selector-list) does not start with a [combinator](https://csswg.sesse.net/selectors-4/#selector-combinator) but does contain the [nesting selector](https://csswg.sesse.net/css-nesting-1/#nesting-selector), it is interpreted as a non-[relative selector](https://csswg.sesse.net/selectors-4/#relative-selector).”

But it doesn't really say what “contain” means. An example we discussed earlier was:

`.foo { :is(.bar, !#&/) { … }}`

Does this “contain” the nesting selector? It has a & in there, but it's thrown away due to parse error (and then forgiving parsing should kick in and retain only `.bar`.). (This is a contrived example, of course, but you could imagine something like `:is(.bar, & >> .foo)` for a hypothetical `>>` combinator. A newer browser would interpret it as selector-containing, an older that did not understand `>>` would not.)

I assume this _doesn't_ contain the nesting selector:

`.foo { :is(/*fluid&flexible*/.bar) { … }}`

but it's difficult to distinguish from the previous case.

Finally, there's also

`.foo { :is(& .bar, .bar) { …}}`

where one side of the :is() contains a nesting selector, which I'd interpret as the entire selector doing so, but it's not 100% obvious.

The simplest thing for us would certainly be to let “contain” mean a properly parsed & somewhere, so the answers here would be no, no, yes, respectively. But if you changed the third case to “no” (requring all arms of the :is() to have & for the :is to be selector-containing), you would probably avoid differences in cases like the first one between old and new browsers.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7972 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 28 October 2022 10:53:11 UTC