[css-selectors] Reconsider removing selector list invalidation

[ExE-Boss]

https://drafts.csswg.org/selectors-4/#grouping

Warning: the equivalence is true in this example because all the selectors are valid selectors. If just one of these selectors were invalid, the entire selector list would be invalid. This would invalidate the rule for all three heading elements, whereas in the former case only one of the three individual heading rules would be invalidated.

I wasn’t aware of that for a long time and wrote many of my stylesheets with the assumption that a single unknown selector in a selector list wouldn’t invalidate the whole selector list¹².

Even in the specification, global selector list invalidation is said to be considered a legacy mistake in appendix B.

I propose to run a web study, similar to what Chrome did in #2156 to see if this very dumb³ legacy mistake can be fixed by getting rid of selector list invalidation.

Footnotes

1. An actual selector list I once wrote:

   /* The `[data-ie]` attribute contains the string "legacy" for IE8 or older,
      and IE8 only supports the single‑colon `::before`/`::after` syntax */
   html[data-ie~="legacy"] pre.line-numbers:before,
   pre.line-numbers::before {
   	content: "1\A 2\A 3\A 4\A 5\A 6\A 7\A 8\A 9\A 10…"; /* all the way up to 9999 */
   }
   

   ↩

2. Current known issues caused by this legacy mistake:

   • MDN bug 1487656 (https://github.com/mozilla/kuma/pull/4961)
   • [selectors] webkit-prefixed pseudo-elements are always treated valid in WebKit and Blink #2156
   ↩

3. Yes, I have a very strong opinion about this. ↩

[SelenIT]

Please consider that the existing behavior is sometimes used as a hack to selectively target a specific browser. For example, people sometimes use selectors like

x:-moz-any-link, .selector { /* this should apply only in Firefox */ } 
_:-ms-input-placeholder, .selector { /* this should apply only in IE10+/Edge */ }

These styles are usually intended to counter some specific browser bugs, so they rely on the presence of this bug in the target browser, and on the absence of these style in other browsers. Exposing such styles to browsers that don't have these bugs would be not web-compatible.

The ::-webkit-craziness case was kind of special because there was time when many web apps (especially mobile ones) were made under assumption that non-WebKit-derived browsers nearly don't exist (at least in mobile world). That forced other browsers to start supporting some -webkit-prefixed features, and eventually even led to the creation of the Compatibility Standard.

[ExE-Boss]

Please consider that the existing behavior is sometimes used as a hack to selectively target a specific browser. For example, people sometimes use selectors like

x:-moz-any-link, .selector { /* this should apply only in Firefox */ } 
_:-ms-input-placeholder, .selector { /* this should apply only in IE10+/Edge¹ */ }

I am aware of that, that’s why I want to run the web study first.

Also, I have yet to actually run into a website using that.

---

¹ That won’t work in Edge, as Edge doesn’t support :-ms-input-placeholder

[SelenIT]

Oops, thanks for the correction!

[jonjohnjohnson]

#3051

[SelenIT]

If we have already started to distinguish the pseudo-elements that don't invalidate the selector list from those that do on a per-prefix basis, maybe it would work the other way round: treat all unknown pseudo-elements as (potentially) valid, except those starting with any prefix other than -webkit-?

From the first glance, this should not break the backwards compatibility, since the most cases of selector-based hacks would be covered with this exception. In the same time, this would allow to add new features in the stylesheets without need to separate things like

.panel:hover, .panel:focus-within { /* styles when the panel is activated by either the mouse or the keyboard */ }

into separate rules (as we have to do currently).

[ExE-Boss]

That sounds like a good idea to me.

Also, add pseudo‑classes to the mix as well, since your example uses pseudo‑classes and it would fix the issue with dumb CSS minimisers merging :matches(…) and the equivalent non‑:matches(…) rules together, which breaks on browsers that don’t support :matches(…) (i.e. anything that (as always) isn’t WebKit‑based)