[selectors] Specify the "all ::-webkit-* pseudos are valid" behavior

[tabatkins]

For a while, WebKit-derived browsers have had a quirk where all ::-webkit-* pseudo-elements are considered valid at parse time (and thus won't invalidate a selector list if they appear in only one selector). This has apparently begun to create compat problems for Firefox (see whatwg/compat#103), so they're adding that behavior themselves. This behavior is being tracked in WPT tests in web-platform-tests/wpt#12673.

We should go ahead and inline that into the Selectors spec, probably in a compatibility appendix.

[tabatkins]

@fantasai and I have gone ahead and added the section to Selectors 4 for discussion.

[frivoal]

It is regrettable that we need this, but Firefox implementing it shows that we do. So yes, this should be in the spec, thanks for writing it.

[upsuper]

The added text is wrong. Only those pseudo-elements need to be valid, pseudo-classes don't. WebKit and Blink doesn't allow arbitrary webkit-prefixed pseudo-class either.

[tabatkins]

Ah, that wasn't clear from the whatwg/compat issue. I'll fix.

[tabatkins]

Fixed in 456e902

[upsuper]

Looks good now, thanks.

[myakura]

Is it hard to limit the list to the currently exposed ::-webkit- pseudo-elements?

[tabatkins]

That's the point of the compat bug - WK-derived browsers accept all pseudo-elements with a -webkit- prefix as valid at parse time, not just ones that they actually know about.

If we can change Blink/WebKit to stop recognizing those as valid, great. But I doubt that's possible, if the quirk has gotten bad enough that Firefox feels the need to implement it.

[myakura]

If we can change Blink/WebKit to stop recognizing those as valid, great.

yeah that was my intent. but after reading #2156 (comment) now I understand it seems impossible (still doubt how and why ~40% of page loads has unknown ::-webkit-whatever though...)

[upsuper]

There are two reasons for Firefox to implement it:

1. Apparently there are websites broken on Firefox due to this.
2. There are other webkit-specific things we may want to make shim to "fix", which would require such rules at least be parsed in stylesheets.

So this is a matter of webcompat directly and indirectly.

[jonjohnjohnson]

Sadly, folks use this hack to target those browsers in order to get around other compat issues, like differences in implementation of the vh unit or position:sticky over the years. Even if an @support rule passes for certain features, this is used to weed out, by hand, the support they want. The past prefix way of things truly led to a muddy present, but rocks and hard places make it so these things need to be dealt with.

[dbaron]

Using hacks that assume support for X is equivalent to support for Y is a bad idea if those hacks are targeting current browsers. Such hacks are safe only if the features are implemented in all current browsers and the equivalence holds in the old versions where they're not implemented.

[css-meeting-bot]

The CSS Working Group just discussed Specify the "all ::-webkit-* pseudos are valid" behavior, and agreed to the following:

• RESOLVED: Accept the proposed change

The full IRC log of that discussion

Topic: Specify the "all ::-webkit-* pseudos are valid" behavior
github: https://github.com//issues/3051
TabAtkins: For a long time webkit based browsers had a quirk where they accept any psuedo element with -webkit at parse time. Won't match, but valid selector.
TabAtkins: FF found this is causing compat problems for them b/c people had used webkit pseudos in the past to select browsers. FF realized they had to match the rules because people doing browser selection.
TabAtkins: roposed we spec that quirk that anything with -webkit prefix i s valid at parsetime
TabAtkins: Put that in an appendix of required but obsolete things.
https://drafts.csswg.org/selectors-4/#compat
emilio: fwiw I think most of this i sn't even intentional. They do ::webkit-scrollbar something that they intend to work and it doesn't in FF.
emilio: If someone knows why webkit hasthis I'd be curious to know
TabAtkins: I suspect it was dumb early parsing code and now we can't remove. If it looks like one of our psuedos let it be valid.
florian: Maybe also b/c there's a bunch of webkit pseudos that only exist on some elements. Maybe checking if valid sometimes was too complex.
TabAtkins: No, validity of selector can't depend on anything in DOM
florian: Right, because you can't person didn't want to check anything because can't check some valid.
dbaron: I think in the past unknown psuedos were jsut accepted. Might have been incomplete fix for that.
plinss: True
plinss: That was why double colon was to allow user defined psuedo elements for templating system.
TabAtkins: Regardless of history, it's h ere. Appears to be necessary for compat. Need to spec.
florian: webkit-whatever is an ident or sart functional notation there?
TabAtkins: No idea. I think start functional notation, have to check
emilio: Doesn't work with functional stuff. In FF we only do identifiers
florian: Okay, good. Less insanity is better.
TabAtkins: Confirmed. Just ident. I'll have to clarify spec text on that
astearns: Concerns with this change?
astearns: Anyone against it?
tantek: I'm not against doing it.
tantek: In light of unproductive comment, might be worth doing a blog post from chairs about this. Seems like a big compat thing to put out there.
tantek: I figure it's indicitive of emotional output. Rather then people discover it and thing we're doing crazy an upfront blog post might diffuse it. Say this sucks but here's why we have to do it.
astearns: We can put a post on CSSWG blog.
s/diffuse/defuse
astearns: I'll wait until TabAtkins does clarification
It might make more sense to put something clarifying in the issue itself rather than having it prominently in the blog?
astearns: Other concerns about this?
astearns: dbaron you're concerned about a blog post because you'd rather not call attention?
dbaron: Don't know if it's worth making that big of a deal. Don't feel strong
fantasai: Agree not make a big deal. If direct concerns we can put comments in issue or add expository notes in the section. People don't need to know about this in general and I don't want to take attention from things that matter. A blog postmight get in front of some people but it's more likely to make more people mad because they know and a vast majority of people that don't care just read a blog post
florian: I suggest FAQ of wiki with an entry of why did you spec this and web compat with details
tantek: It's precieved differently if we do this. They'll appriciate if we're up front. Much worse if someone says look at this crap and puts it on reddit. I agree more people will learn in passing but seeing it from WG it's just hohum as opposed to a 3rd party in another context with exaggeration.
tantek: Hiding or not bringing something up causes things to blow up
fantasai: With webkit prefix we hada blog post. It blew up before we could post. Secondly a blog post puts the explination in a separate place. If you want in front of people you put in spec.
tantek: Spec bigger is worse.
is it not reasonable to do both?
astearns: I'm convinced by argument that explination will b e in spec. You're concerned people will stumble across this and make a big deal. People will stumble across spec and blog is somewhere else.
tantek: I'm okay with the FAQ having a long explination and link to that on blog and spec. Don't like polluting spec with hsitorical drama. Not what they're for
fantasai: Don't think it's complex enough for that much text
fremy: NOt sure it's worthy of a blog post. It's minor. I'm pretty sure Edge has this already ano no one said anything. This is wierd and no one should use it. Not worth calling attention. Few are using.
+1 to fremy
Okay, spec has been updated.
astearns: Concern about spec bigger I don't think is founded. I'm a fan of bigger specs with reason why decisions get in.
+1 to astearns
TabAtkins: Also why we have stying support for details class=note so you can add lots of details without space
bradk: blog would get it in front of eyes to get feedback.
I also folded in a clarification about how to serialize them, since annevk brought up that it was technically undefined.
astearns: Don't htink we're looking for feedback. There's a known compat problems. Fixing because we need not not because it'sgood.
fremy: It's a terrible idea. I don't want people to know this exists.
bradk: There's probably people using it as a hack. Curious how big of a problem that will be.
I'm happy to write a quick explanatory note into the spec.
tantek: astearns I leave it to your judgement. Still think it's a good idea to put something out. If you don't think necessary I trust your judgement
didn't mean to make that comment off the record... I kind of agree that proactive seems better.. I'm not even sure it has to be official csswg, just a member who writes a post we all share is probably ok?
astearns: TabAtkins has been mentioning changes. TabAtkins I would like a note in the spec explaining and appologizing why it's there.
TabAtkins: Spec is live now, writing explanatory note
astearns: Objections to change?
RESOLVED: Accept the proposed change

[jonjohnjohnson]

Years ago, allowing "MQ-style invalidation" for selector lists was seen as unsafe, most likely breaking old sites when it would "activate unexpected declaration blocks". Though I trust @dbaron's opinion on the real issues -webkit- prefixes have caused in gecko, are we sure making the spec tell all vendors to accept selector lists with both unsupported AND then even the supported -webkit- prefixed pseudos is the way forward? This will surely cause current stylesheets to behave in ways their authors won't have realized or intended when previously seeing that those selectors "isolate" styles to webkit?

@fantasai: But this seems to be quite web-incompatible, because people depend on this behavior.
@sylvaing: How do people depend on this?
@glazou: Right now there are style rules which are fully invalid because of one selector, and authors never noticed the wasted rule. If you change, it'll start applying and change the page.
@tabatkins: And there is some history of people using prefixed selectors in the selector list as a browser hack, and this would change the behavior they're depending on.

https://www.w3.org/Style/CSS/Tracker/issues/223
http://lists.w3.org/Archives/Public/www-style/2013Apr/0246.html

[SelenIT]

In #3082, we have a proposal to use the reverse strategy regarding pseudo-elements: treat all unknown pseudo-elements (not just -webkit-prefixed) as potentially valid, except pseudo-elements with other prefixes (most likely used for selector hacks). To me, this seems to be a good idea: it shouldn't break the compatibility (most existing hacks would be covered by the exception), and it would make adopting new features easier as authors wouldn't need to duplicate the entire style rule for the new selector.

Are there any pseudo-elements other than -moz-, -ms-, and probably -o-prefixed ones that were often used as a hack or otherwise were relied on not being applied?