[css-nesting-1] Clearer definition of “nest-containing”

The spec currently reads: “If a selector in the does not start with a combinator but does contain the nesting selector, it is interpreted as a non-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.

Start with the quoted “nest-containing” definition in css-nesting-1 and compare it with the three :is() examples in the issue. Review the linked Selectors definitions, then clarify the specification so each example has an explicit, consistent result.