Re: [csswg-drafts] [css-conditional-4] selector() feature query function for selector support

The CSS Working Group just discussed `Selector feature query function for selectors`.

<details><summary>The full IRC log of that discussion</summary>
&lt;mstange> Topic: Selector feature query function for selectors<br>
&lt;Rossen> github: https://github.com/w3c/csswg-drafts/issues/3207<br>
&lt;mstange> dbaron: When we discussed @supports back w hen we originally did it, one of the things we talked about that we maybe want to have support for more than querying for values<br>
&lt;mstange> dbaron: There may be more important use cases<br>
&lt;mstange> dbaron: Next addition would be testing for selectors<br>
&lt;mstange> dbaron: If you have three comma-separated selectors, the entire rule is supposed to get dropped if any of tehm is unrecognized.<br>
&lt;mstange> dbaron: This is painful because you don't get good negation operations.<br>
&lt;mstange> ... It has also come up recently when looking at scrollbar styling.<br>
&lt;mstange> ... @supports is useless for existing scrollbar styling use cases<br>
&lt;mstange> ... because some of them use selectors<br>
&lt;mstange> ... We all agree on what the syntax of testing for selectors should be, which is, it should be a function called selector.<br>
&lt;mstange> ... We want to allow combinators.<br>
&lt;mstange> ... There are currently some quirks related to ::-webkit pseudo elements<br>
&lt;mstange> ... There is a quirk that makes all ::-webkit pseudo elements not invalidate the selector<br>
&lt;mstange> ... We do not want to carry over this quirk to @supports selector<br>
&lt;mstange> heycam: There is an open question about namespace testing<br>
&lt;myles_> https://bugs.webkit.org/show_bug.cgi?id=189089<br>
&lt;mstange> dbaron: This turns out to be a bug in existing @supports because we didn't define it for content: attr(?)<br>
&lt;mstange> ... We should figure out how it interacts with @namespace prefix declarations<br>
&lt;mstange> TabAtkins: I'm fine with not having them<br>
&lt;mstange> ... I definitely do not want to look at namespace, should either fail or pass always<br>
&lt;mstange> fantasai: I agree<br>
&lt;mstange> dbaron: I would lean towards saying the always succeed and act as they always match the namespace<br>
&lt;mstange> emilio: I would like to argue for the opposite, we sohuld actually look at the namespaces in the stylesheet<br>
&lt;mstange> emilio: If you are testing for a selector that you actually use inside your @supports rule, that's what you want.<br>
&lt;mstange> ... It also doesn't require any special cases in the implementation.<br>
&lt;mstange> Bert: Isn't that the point, to ask whether you support "this type of selector", not "this particular selector"?<br>
&lt;dbaron> s/Bert/plinss/<br>
&lt;mstange> emilio: I would argue that if it's an unknown namespace, you should not go into the @supports rule<br>
&lt;mstange> emilio: Invalid namespaces are invalid, they drop the whole rule<br>
&lt;mstange> emilio: just doing syntactic checking is inconsistent with other DOM APIs that throw on invalid selectors<br>
&lt;mstange> emilio: Like .matches<br>
&lt;mstange> TabAtkins: Can we make them always invalid?<br>
&lt;mstange> emilio: I'd prefer that over making them always valid<br>
&lt;mstange> dbaron: There's a risk with newly-supported selectors in the future<br>
&lt;mstange> emilio: Please don't introduce a special case<br>
&lt;mstange> TabAtkins: The matches function always ignores namespaces, because it always throws when there's a namespace<br>
&lt;mstange> emilio: because there's no stylesheet<br>
&lt;mstange> fantasai: There's a rule in the matches spec that talks about namespaces, but it doesn't make it invalid<br>
&lt;mstange> dbaron: The other thing about the selector functions is that at some point the drafts of those functions had a namespace argument that got dropped.<br>
&lt;mstange> heycam: With CSS prefixes on the DOM node, no namespace prefixes are going to succeed except * or |<br>
&lt;mstange> TabAtkins: That same behavior seems fine to have for @supports<br>
&lt;mstange> fantasai: That doesn't make sense<br>
&lt;mstange> fantasai: I want to check whether I support a selector. Any selector that I'm using in my stylesheet, I should be able to put it into @supports<br>
&lt;mstange> emilio: I agree.<br>
&lt;mstange> fantasai: Which is not what TabAtkins is saying.<br>
&lt;mstange> fantasai: .supports would still return "yes I support namespaces"<br>
&lt;mstange> ... it's not about "Does querySelector" support this<br>
&lt;mstange> fantasai: We're checking things at the syntactic level<br>
&lt;mstange> fantasai: I'd be ok with checking the namespace whether it resolves<br>
&lt;mstange> emilio: I would prefer to look at the namespace map, if it's around<br>
&lt;mstange> emilio: Then we don't conditionally need to make all namespaces valid in some cases.<br>
&lt;mstange> emilio: The rules in @supports should be the same rules as for regular parsing.<br>
&lt;mstange> TabAtkins: What do you think about changing the regular parsing rule of "bad namespaces" kill the rule?<br>
&lt;mstange> futhark: I tend to agree for regular namespaces. If we're not checking namespaces, I prefer that we actually allow namespaces.<br>
&lt;mstange> emilio: So either check the namespace map as normal, or always succeed.<br>
&lt;mstange> dbaron: We need another resolution first, which is to create level 4 of CSS conditional rules<br>
&lt;mstange> ... unless we want to put this in level 3<br>
&lt;mstange> Resolved: Create CSS conditional rules level 4<br>
&lt;mstange> Resolved: Accept selector feature functions for selector support in @supports, accepting a single complex selector as an argument.<br>
&lt;mstange> dbaron: Do we want a resolution or two about the namespace thing?<br>
&lt;heycam> the namespace prefix issue is https://github.com/w3c/csswg-drafts/issues/3220<br>
&lt;mstange> fantasai: For the namespace we've resolved that they're not always invalid.<br>
&lt;mstange> Resolved: Namespaces are either always valid or valid when they're declared.<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3207#issuecomment-432297758 using your GitHub account

Received on Tuesday, 23 October 2018 15:34:24 UTC