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