[css-nesting-1] Invalid nested selectors

[cdoublev]

I think CSS Nesting or CSS Selector 4 (probably the former) should clarify something like "An invalid complex or compound selector remains invalid when some of its parts are nested":

::before {
  &:hover {} /* valid */
  & div {} /* invalid */
}

Currently, in CSS Selector 4:

A pseudo-element may be immediately followed by any combination of the user action pseudo-classes [...].

Note that, unless otherwise specified in a future specification, pseudo-classes other than the user action pseudo-classes are not valid when compounded to a pseudo-element; so, for example, ::before:first-child is an invalid selector.

Some pseudo-elements are defined to have internal structure. These pseudo-elements may be followed by child/descendant combinators to express those relationships. Selectors containing combinators after the pseudo-element are otherwise invalid.

[romainmenke]

see : #7433

this makes me think we could add a warning to the spec that any nesting inside a ::before (or of same type) will produce an invalid selector per https://www.w3.org/TR/selectors-4/#matches-pseudo and have no matches.

[cdoublev]

Changing the title to broaden the topic with the following cases:

type { &type {} }
.subclass { &type {} }

The first can only be invalid, even when expanded using :is().

The latter would be valid only if it is expanded using :is().

The nesting selector can be desugared by replacing it with the parent style rule’s selector, wrapped in an :is() selector.

This currently appear in a note. Maybe it should be normative?

[romainmenke]

Those are only invalid when treating the selectors as strings but that is something only preprocessors do.

I would assume type { &type {} } to be valid because these work fine :

p:is(p) {
	color: green;
}

is(p):is(p) {
	color: green;
}

---

This currently appear in a note. Maybe it should be normative?

I agree, because in practice these are tightly coupled :

• Blink is implementing nesting based on :is() internals.
• pseudo elements have the same restrictions

[cdoublev]

Yeah, Romain, you are right: p { &p {} } could be valid, and p { &div {} } could just match nothing.

---

The nesting selector is allowed anywhere in a compound selector, even before a type selector, violating the normal restrictions on ordering within a compound selector.

svg { &|rect {} }: is it valid or does the above definition means anywhere at the "top-level" of <compound-selector>?

EDIT: nope, it seems not, according the note related to the BEM pattern, which should also be normative, imo, therefore I think the above definition can be clarified.

[romainmenke]

svg { &|rect {} }: is it valid or does the above definition means anywhere at the "top-level" of <compound-selector>?

Also somewhat related to : #7972

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

[tabatkins]

For the question in the OP, this is a dupe of #2880.

type1 { &type2 {...}} is indeed perfectly valid, equivalent to type2:is(type1) {...}. It won't match anything, but that's fine.

svg { &|rect {} } is also valid, equivalent to |rect:is(svg) - it only matches an element which is an <svg> and is a <rect xmlns="">, which again won't match anything, but that's still fine. ^_^

[cdoublev]

I did not asked how to handle invalid nested style rules but if a selector of a nested style rule that would be invalid when desugared, should be invalid.

I do not know how selectors in ::before { &:root {} }, :root { &::before {} }, type { &::before {} }, type { undeclared|& {} }, .class { html|& {} }, etc, are supposed to be desugared and validated using :is().

Example 10 seems to be defining that selectors that would be invalid (like & representing pseudo-element, ie. the first example) are just ignored, which is surprising because parsing the top-level selector is not forgiving.

For example, html|:hover, .class:hover {} is entirely invalid but :hover { html|&, .class& {} } would be valid?

Anyway, I will wait for the next edits of the spec.