Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
tabatkins opened this Issue Aug 24, 2018 · 15 comments

Comments

Projects
None yet
8 participants
@tabatkins
Copy link
Member

tabatkins commented Aug 24, 2018

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

This comment has been minimized.

Copy link
Member Author

tabatkins commented Aug 24, 2018

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

@frivoal

This comment has been minimized.

Copy link
Collaborator

frivoal commented Aug 24, 2018

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

This comment has been minimized.

Copy link
Member

upsuper commented Aug 24, 2018

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

This comment has been minimized.

Copy link
Member Author

tabatkins commented Aug 24, 2018

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

@tabatkins

This comment has been minimized.

Copy link
Member Author

tabatkins commented Aug 24, 2018

Fixed in 456e902

@upsuper

This comment has been minimized.

Copy link
Member

upsuper commented Aug 24, 2018

Looks good now, thanks.

@myakura

This comment has been minimized.

Copy link

myakura commented Aug 26, 2018

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

@tabatkins

This comment has been minimized.

Copy link
Member Author

tabatkins commented Aug 26, 2018

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

This comment has been minimized.

Copy link

myakura commented Aug 26, 2018

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

This comment has been minimized.

Copy link
Member

upsuper commented Aug 26, 2018

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

This comment has been minimized.

Copy link

jonjohnjohnson commented Aug 26, 2018

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

This comment has been minimized.

Copy link
Member

dbaron commented Aug 27, 2018

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.

foolip added a commit to web-platform-tests/wpt that referenced this issue Aug 27, 2018

Update webkit-pseudo-element test with correct spec link. (#12683)
To reflect that this was added into selectors spec rather than compat spec,
and update the link correspondingly.

Related to w3c/csswg-drafts#3051.

zcorpan added a commit to web-platform-tests/wpt that referenced this issue Aug 27, 2018

Update webkit-pseudo-element test with correct spec link. (#12683)
To reflect that this was added into selectors spec rather than compat spec,
and update the link correspondingly.

Related to w3c/csswg-drafts#3051.

@w3c w3c deleted a comment from MrSorcus Aug 29, 2018

@css-meeting-bot

This comment has been minimized.

Copy link
Member

css-meeting-bot commented Aug 29, 2018

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 <dael> Topic: Specify the "all ::-webkit-* pseudos are valid" behavior
<dael> github: https://github.com//issues/3051
<dael> 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.
<dael> 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.
<dael> TabAtkins: roposed we spec that quirk that anything with -webkit prefix i s valid at parsetime
<dael> TabAtkins: Put that in an appendix of required but obsolete things.
<TabAtkins> https://drafts.csswg.org/selectors-4/#compat
<dael> 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.
<dael> emilio: If someone knows why webkit hasthis I'd be curious to know
<dael> 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.
<dael> 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.
<dael> TabAtkins: No, validity of selector can't depend on anything in DOM
<dael> florian: Right, because you can't person didn't want to check anything because can't check some valid.
<dael> dbaron: I think in the past unknown psuedos were jsut accepted. Might have been incomplete fix for that.
<dael> plinss: True
<dael> plinss: That was why double colon was to allow user defined psuedo elements for templating system.
<dael> TabAtkins: Regardless of history, it's h ere. Appears to be necessary for compat. Need to spec.
<dael> florian: webkit-whatever is an ident or sart functional notation there?
<dael> TabAtkins: No idea. I think start functional notation, have to check
<dael> emilio: Doesn't work with functional stuff. In FF we only do identifiers
<dael> florian: Okay, good. Less insanity is better.
<dael> TabAtkins: Confirmed. Just ident. I'll have to clarify spec text on that
<dael> astearns: Concerns with this change?
<dael> astearns: Anyone against it?
<dael> tantek: I'm not against doing it.
<dael> 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.
<dael> 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.
<dael> astearns: We can put a post on CSSWG blog.
<tantek> s/diffuse/defuse
<dael> astearns: I'll wait until TabAtkins does clarification
<dbaron> It might make more sense to put something clarifying in the issue itself rather than having it prominently in the blog?
<dael> astearns: Other concerns about this?
<dael> astearns: dbaron you're concerned about a blog post because you'd rather not call attention?
<dael> dbaron: Don't know if it's worth making that big of a deal. Don't feel strong
<dael> 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
<dael> florian: I suggest FAQ of wiki with an entry of why did you spec this and web compat with details
<dael> 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.
<dael> tantek: Hiding or not bringing something up causes things to blow up
<dael> 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.
<dael> tantek: Spec bigger is worse.
<bkardell_> is it not reasonable to do both?
<dael> 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.
<dael> 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
<dael> fantasai: Don't think it's complex enough for that much text
<dael> 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.
<fantasai> +1 to fremy
<TabAtkins> Okay, spec has been updated.
<dael> astearns: Concern about spec bigger I don't think is founded. I'm a fan of bigger specs with reason why decisions get in.
<dauwhe> +1 to astearns
<dael> TabAtkins: Also why we have stying support for details class=note so you can add lots of details without space
<dael> bradk: blog would get it in front of eyes to get feedback.
<TabAtkins> I also folded in a clarification about how to serialize them, since annevk brought up that it was technically undefined.
<dael> astearns: Don't htink we're looking for feedback. There's a known compat problems. Fixing because we need not not because it'sgood.
<dael> fremy: It's a terrible idea. I don't want people to know this exists.
<dael> bradk: There's probably people using it as a hack. Curious how big of a problem that will be.
<TabAtkins> I'm happy to write a quick explanatory note into the spec.
<dael> 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
<bkardell_> 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?
<dael> astearns: TabAtkins has been mentioning changes. TabAtkins I would like a note in the spec explaining and appologizing why it's there.
<dael> TabAtkins: Spec is live now, writing explanatory note
<dael> astearns: Objections to change?
<dael> RESOLVED: Accept the proposed change
@jonjohnjohnson

This comment has been minimized.

Copy link

jonjohnjohnson commented Aug 29, 2018

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

moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Aug 31, 2018

Bug 1486171 [wpt PR 12683] - Update webkit-pseudo-element test with c…
…orrect spec link, a=testonly

Automatic update from web-platform-testsUpdate webkit-pseudo-element test with correct spec link. (#12683)

To reflect that this was added into selectors spec rather than compat spec,
and update the link correspondingly.

Related to w3c/csswg-drafts#3051.
--

wpt-commits: 04d0c8c0d8f8f9f0e91881be731fd344477573dc
wpt-pr: 12683

jankeromnes pushed a commit to jankeromnes/gecko that referenced this issue Aug 31, 2018

Bug 1486171 [wpt PR 12683] - Update webkit-pseudo-element test with c…
…orrect spec link, a=testonly

Automatic update from web-platform-testsUpdate webkit-pseudo-element test with correct spec link. (#12683)

To reflect that this was added into selectors spec rather than compat spec,
and update the link correspondingly.

Related to w3c/csswg-drafts#3051.
--

wpt-commits: 04d0c8c0d8f8f9f0e91881be731fd344477573dc
wpt-pr: 12683
@SelenIT

This comment has been minimized.

Copy link
Collaborator

SelenIT commented Sep 7, 2018

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.