[selectors-4] Allow more pseudo-classes following a pseudo-element

[cdoublev]

There is already an issue mentioned in 3.6.3. Pseudo-classing Pseudo-elements (I did not find the corresponding issue on GH):

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

ISSUE 3 Clarify that :not() and :is() can be used when containing above-mentioned pseudos.

I think the issue can be completed with:

• all pseudo-classes: when following a pseudo-element explicitly defined to be matchable by this pseudo-class (eg. ::shadow:empty, ::shadow:defined, ::shadow-child:first-child, etc)
• :where(): when containing user-action pseudo-classes as arguments
• :defined: I'm not sure about this one because it is defined as matching elements that are fully defined, as dictated by the host language, not as matching pseudo-element

Pseudo-class functions which do not match the corresponding (pseudo-element) sub-classing condition could be considered as matching nothing instead of being invalid.

But I wonder if I'm missing something because:

• ::before:hover does not work in Chrome/Firefox (not tested in other browsers)
• MDN browser compat table includes Pseudo-element support with support from early versions of all browsers: is it the support of :hover followed by a pseudo-element, or the other way around? The french version defines that the :hover pseudo-class can follow any pseudo-element, but not the english version. Non-english versions are often translations of the english text.
• I could not find any related issues on Chromium Issues or Mozilla Firebug Bugzilla
• EDIT: I missed the related issue on Bugzilla and created an issue on Chromium Issues
• Chrome DevTools does not allow to simulate user-action pseudo-classes like :hover on a pseudo-element (cf. this SO issue)
• Firefox DevTools allows to set :hover but it triggers this state on the originating element

[SebastianZ]

I could not find any related issues on Chromium Issues or Mozilla Firebug

Nice to read Firebug! 😄 One related Firefox/Gecko issue is here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1122965

I couldn't find one for Chromium or WebKit.

Sebastian

[Loirooriol]

This seems related to #6737 in the sense that some contexts restrict which selectors you can use, then :is()/:where()/:not() should probably be allowed but with their argument obeying the restriction.

[fantasai]

Agenda+ to discuss allowing :is()/:not()/:where()

• after pseudo-elements, when restricted to containing the user-action pseudos (which are already allowed there)
• generically stated, anywhere their arguments are allowed

See pull request #8041

[Loirooriol]

provided their arguments all adhere to the above restriction

Does this mean that ::before:is(:hover, :first-child) is completely invalid, or becomes ::before:is(:hover)?

[fantasai]

@Loirooriol Good question, ::before:first-child is invalid, but since :is() has forgiving parsing maybe it should be valid?

[css-meeting-bot]

The CSS Working Group just discussed Allow more pseudo-classes after pseudo-elements, and agreed to the following:

• RESOLVED: allow the "logical combination pseudo-classes" after pseudo-elements, with their contents having the same restrictions as the pseudo-elements themselves otherwise would have
• RESOLVED: Allow the logical-combination pseudo-classes generically, anywhere their contents are allowed.
• RESOLVED: Allow pseudo-elements to define additional pseudo-classes they allow to be placed after them.

The full IRC log of that discussion

<TabAtkins> Topic: Allow more pseudo-classes after pseudo-elements
<fantasai> TabAtkins: Currently, pseudo-elements allow a few pseudos to be put after them, :hover etc.
<fantasai> TabAtkins: question is whether to allow combinatoric ones (:is()/:not()/:where()) to be applied as well
<JakeA> q+
<fantasai> TabAtkins: Further, some pseudo-elements represent specific elements elsewhere in the DOM
<fantasai> TabAtkins: wondering if specific pseudo-elements can opt into allowing additional pseudo-elements
<fantasai> TabAtkins: but that's a different issue
<fantasai> TabAtkins: but first issue, allowing combinatoric ones
<fantasai> TabAtkins: Contents are still restricted to the user-action pseudos
<fantasai> JakeA: we're interested in this for view-transitions
<Rossen_> ack JakeA
<fantasai> JakeA: want to know if old or new view is only-child
<fantasai> JakeA: so allowing that would be useful
<TabAtkins> fantasai: two issues, one is we have a set of pseudos that are already allowed, and do we allow them to be put in :is()/etc
<TabAtkins> fantasai: second is allowing other pseudos on case-by-case basis, we should talk about that separately
<TabAtkins> fantasai: for is/not/where, it's about whether we can express the combinations of the user action pseudos
<fantasai> https://github.com//pull/8041/files
<tantek> could see this being useful for webdevs
<fantasai> oriol: these use forgiving parsing, would invalid pseudos be valid within them?
<fantasai> TabAtkins: yes
<fantasai> TabAtkins: this would allow more safely adding more pseudo-classes to a selector in the future
<fantasai> Rossen_: any other opinions?
<fantasai> TabAtkins: proposed, allow the "logical combination pseudo-classes" after pseudo-elements, with their contents having the same restrictions as the pseudo-elements themselves otherwise would have
<fantasai> RESOLVED: allow the "logical combination pseudo-classes" after pseudo-elements, with their contents having the same restrictions as the pseudo-elements themselves otherwise would have
<TabAtkins> fantasai: and more generically i want to resolve that the logical-combo pseudos can be used *anywhere* their contents are allowed
<TabAtkins> TabAtkins: I agree with being more generic if we can get away with it
<fantasai> fantasai: wanted to ask if anyone saw a problem with that
<tantek> no objection
<TabAtkins> (Don't think there's much issue beyond just implementing it.)
<TabAtkins> RESOLVED: Allow the logical-combination pseudo-classes generically, anywhere their contents are allowed.
<fremy> q+
<fantasai> TabAtkins: Second part of issue, should we allow additional pseudo-classes other than user-action pseudo-classes to be put after speudo-elements?
<fantasai> s/speu/pseu/
<fantasai> fremy: On previous resolution, does that mean you can change styles on ::before:hover ?
<fantasai> TabAtkins: yes
<fantasai> fremy: what if you create a loop with ::first-line:hover?
<fantasai> TabAtkins: hover loop, we already have that problem
<fantasai> Consider p:hover ::first-line
<fantasai> fremy: ok
<JakeA> I'm still +1 this
<bradk> +1
<fantasai> TabAtkins: back to issue, should we allow lifting restrictions on pseudo-elements followed by pseudo-classes?
<argyle> +1
<miriam> +1
<JakeA> q+
<Rossen_> ack fremy
<TabAtkins> fantasai: Okay as long as we do it as an allowlist, rather than blanket allowing
<Rossen_> ack JakeA
<TabAtkins> JakeA: would folks be happy with us using :only-child for view transitions?
<fantasai> TabAtkins: As long as it matches intent
<fantasai> TabAtkins: defined as up to two children, and this one says if you have only one
<fantasai> JakeA: But usually it doesn't count pseudos...
<fantasai> JakeA: but I guess if we're appying it to a pseudo
<bradk> :only-pseudo-element?
<fantasai> TabAtkins: pseudo-elements live in the tree
<TabAtkins> RESOLVED: Allow pseudo-elements to define additional pseudo-classes they allow to be placed after them.

[cdoublev]

So basically, the basic syntax of the argument of logical combination pseudo-classes following a pseudo-element is now allowed to be a very small subset of <*-selector-list> specific to the pseudo-class and the pseudo-element.

It would be nice to define this syntax explicitly, to avoid parsing against <forgiving-selector-list> whereas a simple list of user action pseudo-class selectors would be expected.

I do not think pseudo-elements are focusable so user actions do not even need to be stackable, and the basic syntax of the argument of :is() or :where() following a pseudo-element could be <user-action-pseudo-class-selector>#, which is way more efficient to parse than <forgiving-selector-list>, I think.

EDIT: on second thought, implementers may not be fans of context-sensitive syntaxes and it may be simpler to validate the result of parsing against <*-selector-list>.