- From: Daniel Glazman via GitHub <sysbot+gh@w3.org>
- Date: Tue, 30 Jan 2018 09:05:47 +0000
- To: public-css-archive@w3.org
> We're not renaming :matches(); it's already shipped in Safari and I think Firefox and Chrome are soon to ship? Could we have metrics about current :matches() usage in the wild? @inoas 's argument « So since when has short-lived vendor implementation ruled what happens to a standard? » does ring a bell here. If, as @LeaVerou says, :matches() is unused or almost unused (plausible since 95% of the market does not have it yet), we have NOW a window of opportunity to change it if we want. That said, I am not sure I like the "as" extra argument proposal. In terms of parsing, we would need a separator between the end of the last compound selector and the specificity marker to avoid confusion with a "as" type element selector... The easiest to use is the comma but then we have the same problem again, the selector list parser will resume with "as" and only a look-ahead will help; but still, what if I'm applying "as f0" selector to my own XML dialect where "as" and "f0" are real elements but I make a typo and drop the leading "f"? Is that a buggy selector list or a buggy specificity marker? All in all, the ", as ..." solution seems to me too hacky. I have then a preference for two pseudos, one with a specificity and a second one without. Extra note, I don't like the fact that two features having same exact definition if you except the specificity have too different names. That's why I don't really like :is(). I would prefer :matches() and :matches-_blah_() with a good choice for _blah_... > AFAIK, :matches() is not just "short-lived vendor implementation". It has been in the standard draft for years (although the definition has changed a little), and its shipped implementation, without any flag/prefix, has existsed since mid-2015 (deprecating the old vendor-specific :-webkit-any() implementation), and there is intent to implement it in Blink (1, 2). So there should be some really solid reasons to rename/alias it (IMO). A "draft" is NOT a standard. Second, Selectors 4 have never been in CR, and :matches() has never been in a REC-track version of Selectors 3. So this is yet another occurrence of vendors potentially disturbing standardization with a "shipped, can't change" argument and, holy cow it's 2018, could vendors please stop doing that? Oh but wait, it's not even shipped yet, an "intent to ship" is not "shipped". It smells far too much like 1997 Microsoft and, fortunately, Microsoft stopped doing that two decades ago. -- GitHub Notification of comment by therealglazou Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2143#issuecomment-361523501 using your GitHub account
Received on Tuesday, 30 January 2018 09:07:19 UTC