- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 07 Nov 2017 22:31:11 +0000
- To: public-css-archive@w3.org
The Working Group just discussed `Functional pseudo-class like :matches() with 0 specificity`, and agreed to the following resolutions: * `RESOLVED: Add to selectors level 4 with a TBD name.` <details><summary>The full IRC log of that discussion</summary> <leaverou> topic: Functional pseudo-class like :matches() with 0 specificity<br> <eae> leaverou: As we all know specificity tries to infer importance from selectors. Resulting specificity might not always be logical.<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/1170<br> <Chris_> github, delete all comments<br> <eae> leaverou: My favorite example of specificity not being a good heuristic is using the not pseudo class.<br> <leaverou> div:not(#foo):not(#bar):not(#baz)<br> <eae> leaverou: ^^^<br> <eae> leaverou: In this example we want to target all dives except three, yet gets very high specificity.<br> <eae> leaverou: Especially for libraries, when trying to be specific, it is hard to override.<br> <eae> leaverou: uses something called BAM(?) encodes selector in class name and uses js to apply it.<br> <bradk_> BEM<br> <TabAtkins> s/BAM/BEM/<br> <Chris_> .how__many__people__have__hear__of__bem<br> <eae> leaverou: Willing to not use selectors at all, to bypass specificity.<br> <bradk_> http://getbem.com/introduction/<br> <eae> leaverou: One way to fix this would be to define selectors with a known specificity of one, would allow last selector win and make it easier to override.<br> <fantasai> q+<br> <eae> leaverou: I.e. put all nots in a single pseduo class. Easy solution vs other ones like per origin.<br> <eae> leaverou: Lets one be very specific with regardess to specificty, can be selected per selector and solves most of the known problems.<br> <eae> leaverou: Something that could be done as a pre-processor.<br> <eae> leaverou: Many names have been proposed, we can bikeshed that.<br> <eae> fantasai: Seems like a reasonable idea to me. The fact that authors can chose which parts of the selector applies to specificity sounds good to me.<br> <bkardell_> ?+<br> <eae> fantasai: Lower priority for an entire style sheet, library author might want to allow the entire stylesheet to be allowed to be overriden by author rules.<br> <Rossen> q?<br> <eae> leaverou: Example: in ?? there is a toolbar that has a class of mv-bar, also class of mv-ui that means applpy default style. Want author to be able to overrule using just mv-bar but I don't want their "div" rules to override.<br> <bradk_> q+<br> <astearns> s/??/mavo/<br> <Rossen> ack fantasai<br> <Rossen> ack bkardell_<br> <eae> bkardell_: I don't think they are mutually exclusive. May be that you can do an awful lot for a whole bunch of things and we know we can do that easily.<br> <eae> bkardell_: For a number of polyfills that I have worked on this would have been really useful.<br> <eae> bkardell_: There are things like headings that need to take aria roles into account that make them have very high specificity which makes it hard to override.<br> <TabAtkins> q+<br> <Rossen> ack bradk_<br> <eae> bradk_: Seems to me like we could solve this without taking specificity all the way down to zero.<br> <eae> bradk_: Specificty only matters when there is a tie.<br> <eae> bradk_: If there is a tie when it comes to ID or class, if the ID selector inside the funciton was more specific then outside the function that would solve the same problem while still allowoing specificity.<br> <Rossen> q?<br> <fantasai> Dael, here's the diagrams for Nat's presentation on line grids; please insert them in the correct section of the minutes. :) https://lists.w3.org/Archives/Public/www-archive/2017Nov/att-0008/CSSWG_2017.11.6_nmccully.pdf<br> <eae> leaverou: As dicussed in issue, if we have fractions of specificity that introduces new levels of specificity and no one is suggestion that the entire thing doesn't have specicifity. All the classes and IDs outside of it still applies. It allows the specificity to be controlled. To have it count as a class you would just add it to the end, a bit hacky.<br> <eae> bradk_: No use case for specifying it for the entire selector?<br> <eae> leaverou: Yes but usaully not. You would only want to [put some criteria in the pseduo class. Like all the not for example.<br> <eae> leaverou: Makes it less predictable. Now we know that we can count the number of IDs, number of classes, tags etc. If it is always zero it is very obiovus, if not it makes it much more complciated to compute it.<br> <Rossen> q?<br> <Rossen> ack TabAtkins<br> <eae> TabAtkins: I agree in general with what leaverou is saying. Authors can often do just fine when specificity is in order. Opting out or in-order seems ot match what users want.<br> <eae> TabAtkins: AS for chrome, we're happy with this, and would like to implement the stornger version of matches. This is easier, we might do this firts.<br> <eae> TabAtkins: We're supportive.<br> <Rossen> q?<br> <eae> florian: Let's put this in level 4 for now, we don't have a five.<br> <eae> fantasai:<br> <eae> Rossen: Let's add it to four.<br> <eae> fantasai: Very simple feature, as long as we're happy with the name.<br> <eae> ericwillgers: What about web platform tests?<br> <eae> fantasai: Not in CR yet, not needed.<br> <eae> <laughter><br> <dbaron> q+<br> <eae> dbaron: One comment: I think it is worth nothing that it is not clear how easy it would be to implement matches. This has most of the same risk.<br> <Rossen> ack dbaron<br> <eae> dbaron: One of the things with selectors, they're heavily optimized. Implementing without optimizaions not very useful. With optimizations is quite a bit of work and not clear how quickly that can happen.<br> <eae> fantasai: Start with implemented subset.<br> <eae> TabAtkins: WebKit goes beyond spec, also has support for pseduo elements.<br> <eae> dbaron: Caution in that it's being tied to a feature which has an uncertain future.<br> <eae> fantasai: De-risk by having certain things in level 4 vs 5.<br> <eae> dbaron: Other alternatives that solves leaverou use cases.<br> <eae> leaverou: I don't want to reduce *all* of it to zero but only a part.<br> <bkardell_> ?+<br> <Chris_> q?<br> <eae> dbaron: I don't have a syntax proposal at this time but would avoid tie to branching combinators.<br> <eae> TabAtkins: Earliest version didn't support that, does not.<br> <eae> does now.<br> <bkardell_> ?-<br> <eae> fantasai: Making up a completely new unrelated syntax seems silly and doesn't make sense. Cut down on the syntax instead.<br> <Rossen> q?<br> <eae> dbaron: What doesn't make sense to me is spec moving so far ahead of what implementors are willing to do. Implementor by-in was not a factor.<br> <eae> fantasai: Disagree, you're arguing against it based on implementation priority.<br> <Chris_> s/by-in/buy-in<br> <eae> dbaron: you're acting like we can only do everything or nothing.<br> <fantasai> eae, that's not what I said<br> <eae> fantasai: Not what I said.<br> <fantasai> at all<br> <eae> dbaron: I'm fine with the proposal but I do not think it's the only one.<br> <eae> leaverou: If implementors aren't willing to do that at the moement shouldn't we discuss that?<br> <eae> dbaron: I think I bought this up when we went to CR<br> <eae> fantasai: Selectors are not in CR yet.<br> <eae> dbaron: But people are goimg ahead to implement it.<br> <leaverou> s/aren't willing to do that/aren't willing to implement a part of :matches()/<br> <eae> dbaron: This is the problem with sticking things in editors draft.<br> <fantasai> There shouldn't be anything in Selectors that didn't have a WG resolution to add.<br> <eae> Rossen: Would you prefer to see this go in in another way? If not can we try to settle on a resoluiton and go on.<br> <fantasai> If there is, the editors made a mistake.<br> <fantasai> If there was a resolution and you didn't like it you should have objected.<br> <eae> dbaron: Fine with matches without combinators under a different name.<br> <fantasai> Being angry about it now is neither helpful nor fair.<br> <bkardell_> q+<br> <eae> leaverou: I'm fine with that (adding combinators later)<br> <eae> TabAtkins: The no combinators version is the one that desugars effecitvely. Start with simple version.<br> <eae> leaverou: Still supports commas, right?<br> <Rossen> q?<br> <eae> TabAtkins: Yes<br> <eae> bkardell_: Is there a suggestion to take combinators out of matches level 4 as well?<br> <eae> TabAtkins: Yes<br> <eae> Rossen: Are you OK with that?<br> <eae> leaverou: Yes, can we have a resolution?<br> <dbaron> fwiw, we did discuss moving selectors4 to cr at least in https://lists.w3.org/Archives/Public/www-style/2015Jul/0349.html<br> <eae> Proposed resolution: Add to selectors level 4 with a TBD name<br> <eae> RESOLVED: Add to selectors level 4 with a TBD name.<br> <eae> fantasai: Do we have a list of candidate names?<br> <eae> leaverou: is, when, and filter<br> <eae> Rossen: Any particular favorite we can resolve on right now?<br> <eae> ericwilingers: I like filter<br> <eae> Rossen: filter has the most plusses on github?<br> <eae> leaverou: No, I think it was either is or when.<br> <dbaron> filter is also the name of a property<br> <eae> Rossen: You all work it out.<br> <eae> Rossen: let's move on.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1170#issuecomment-342645651 using your GitHub account
Received on Tuesday, 7 November 2017 22:31:13 UTC