- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 16 Sep 2022 21:18:13 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `At-rule Prelude Tests`.
<details><summary>The full IRC log of that discussion</summary>
<fantasai> Topic: At-rule Prelude Tests<br>
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/6966<br>
<fantasai> TabAtkins: earlier we defined testing for at-rules and descriptors, which we can do generically by throwing it at a parser<br>
<fantasai> TabAtkins: we don't have ability to check if prelude of atr-ule is valid or not<br>
<fantasai> TabAtkins: this should follow the same "throw at parser and see", but not possible atm<br>
<fantasai> TabAtkins: especially important for at-rules that don't have blocks, e.g. @layer statement form<br>
<fantasai> TabAtkins: you can test @layer at all, but not specifically for @rule statements<br>
<fantasai> TabAtkins: suggest we take the first form of the at-rule syntax and allow it to take more<br>
<fantasai> TabAtkins: parse all of that as the prelude<br>
<miriam> q+<br>
<fantasai> TabAtkins: as long as it passes your parser check, it's OK<br>
<heycam> q+<br>
<fantasai> miriam: I think this is also required for testing whether style queries are supported<br>
<astearns> ack heycam<br>
<fantasai> heycam: I'm wondering if there's any benefit from having this called "rule" rather than "at-rule", can we match any kind of rule not just at-rules?<br>
<fantasai> TabAtkins: unless you know the context you're parsing in, there's only one type of rule and it's style rule<br>
<fantasai> heycam: for those rules you can rely on selectors and individual properties<br>
<heycam> fantasai: to summarize, three parsing forms for at-rule function<br>
<heycam> ... one just takes the name<br>
<heycam> ... one takes the entirety of the rule, and if anything is dropped, then it returns false<br>
<fantasai> https://github.com/w3c/csswg-drafts/issues/6966<br>
<heycam> ... and the third is the existing descriptor, `@foo; descriptor:value`<br>
<TabAtkins> at-rule(@foo bar {baz: qux}),<br>
<fantasai> fantasai: That would let you do complicated nesting structures as well<br>
<fantasai> TabAtkins: If feed into parser, is the top-level rule kept or not. Ignoring inside things.<br>
<heycam> fantasai: I think that would not be hepful<br>
<fantasai> TabAtkins: more specific, would require more specific plumbing in browsers<br>
<fantasai> TabAtkins: to report pass or failure<br>
<fantasai> TabAtkins: and also it's more powerful than you necessarily wanted<br>
<heycam> fantasai: I think if we want to add a full whole thing kind of syntax, then we should be parsing everything in there and if anything is dropped, you fail<br>
<heycam> ... if you want it more limited<br>
<heycam> ... if you want to check statement vs block, then add curly quotes<br>
<heycam> ... as soon as you put something in there, authors will expect it's testing everything in there<br>
<heycam> ... if we allow dropped things, authors will be confused, and we won't have an extension mechanism in the future<br>
<heycam> fantasai: authors are going to expect that when you put a test in @supports it's everything you put in there that you're checking<br>
<florian> q+<br>
<heycam> fantasai: fine to add more specific syntaxes, but authors are going to expect if you add in @supports, it's checking the full thing is understood<br>
<heycam> miriam: I agree<br>
<heycam> emilio: yes<br>
<fantasai> TabAtkins: That is something that was specifically called out, that bubling up invalidity is problematic<br>
<chris> s/emilio/chris/<br>
<heycam> TabAtkins: that was specifically called out as problematic in an earlier discussion<br>
<heycam> fantasai: so limit the syntax<br>
<heycam> fantasai: that's fine, if you want to do nested structures, do it properly<br>
<astearns> ack florian<br>
<fantasai> ^TabAtkins: then do nested structures<br>
<fantasai> florian: We don't want @supports to be smart. Want to use the actual parser<br>
<fantasai> florian: if we start to maintain some degree of logic, then that logic can get out of sync with reality<br>
<fantasai> s/do nested/don't do nested/<br>
<fantasai> s/don't/can't/<br>
<fantasai> florian: usefulness of at-supports will decrease if we try to be smart about it, because will be less reliable<br>
<heycam> fantasai: I think it's more important that anyything we allow in @supports ,the author can rely it's testing the whole thing<br>
<heycam> ... I think that's more important than the concern that it might get out of sync<br>
<heycam> TabAtkins: I disagree. author confusion is substantially better than UA lying.<br>
<heycam> fantasai: the UA is effectively lying from the perspective of the author<br>
<emilio> q+<br>
<fantasai> fantasai: if you let it ignore stuff that is inside @supports check<br>
<fantasai> astearns: This is an issue about preludes, so how about we just add preludes and not address nesting<br>
<fantasai> TabAtkins: so we would just take the prelude, not semicolon<br>
<astearns> ack emilio<br>
<fantasai> emilio: I agree with TabAtkins, it's weird to suddenly pass e.g. @font-face rule, and you read the descriptors and the ones you care about you keep and the others you ignore<br>
<TabAtkins> Authors being confused means the author can fix this, by doing it right. UAs lying means the author can't fix this; they're just screwed. UA lying is *meaningfully different* from author confusion.<br>
<fantasai> emilio: it would require this special mode, then you have to find the places<br>
<heycam> fantasai: I'm not arguing with you on this point<br>
<heycam> ... if you're going to allow the syntax in @supports, then you must check all of it<br>
<heycam> ... if you don't want that, don't allow it in the syntax<br>
<fantasai> astearns: So proposed resolution is allow @rule preludes in the syntax, and check them for validity<br>
<fantasai> fremy: You have at-rule in the prelude, what if at-rule is only valid inside another at-rule?<br>
<fantasai> TabAtkins: This should still be fine, you won't be able to do any parent-child checking<br>
<fantasai> TabAtkins: but this sub-atrule gets parsed somehow<br>
<fantasai> TabAtkins: only problem is if you have two different at-rules that have different children with different names<br>
<TabAtkins> s/different name/same names/<br>
<astearns> ack fantasai<br>
<heycam> fantasai: if I say @at-rule(@media foo), will that parse as supporting querying against foo?<br>
<heycam> ... that's not going to cause the media rule to be invalidate, I'm asking whether you support that media rule<br>
<florian> q+<br>
<heycam> ... if it's going to return true for anything that appears after @media, that's not useful<br>
<heycam> TabAtkins: [missed]<br>
<fantasai> s/useful/useful, and it is confusing and unexpected to the author/<br>
<fantasai> emilio: We have custom parsing for unforgiving selectors, right?<br>
<fantasai> TabAtkins: Still, I suspect that this is a distinctly different thing because switching between selector lists isn't straightforward<br>
<fantasai> emilio: but there is some amount of precedent, not that I love it<br>
<fantasai> florian: for fantasai's example about media queries, it's undecideable<br>
<fantasai> florian: because, telling the difference between whether you support querying whether running on 3D printer vs asking, you can't distinguish as an author<br>
<heycam> fantasai: let's take a better example<br>
<fantasai> florian: you'll get a "no", which is the correct answer<br>
<fantasai> fantasai: consider the touchscreen MQ<br>
<heycam> ... if the author asks do you support querying whether this is a touchscreen, and you say sure, I support every media query ever<br>
<heycam> ... then the author will assume you support the media query<br>
<heycam> TabAtkins: they'll get a no when they actually use the MQ<br>
<heycam> fantasai: maybe they want to figure out some other heuristics?<br>
<heycam> ... maybe I'll change my layout if you don't support this MQ, and cannot know from the MQ whether you support a touchscreen<br>
<heycam> ... but you don't have the ability to check that<br>
<heycam> ... not saying you necessarily don't need this feature, I am saying if you put it in an @supports query, the author will reasonably expect the browser will check if it understands that MQ, and we should not violate that expectation<br>
<fantasai> TabAtkins: Anything that requires custom parsing<br>
<fantasai> fantasai: then don't allow it<br>
<fantasai> TabAtkins: either you can never test for preludes, or for some extremely forgiving syntaxes, this query is not going to be maximally useful<br>
<fantasai> TabAtkins: and we can introduce a new query later<br>
<fantasai> TabAtkins: either we don't allow preludes at all, or we accept that @media is confusing<br>
<TabAtkins> TabAtkins: And we fix it in the future with a `media-feature()` query<br>
<fantasai> astearns: Is that going to be acceptable, to allow testing for preludes with this possibly workaroundable thing?<br>
<fantasai> fantasai: depends what other people think? I'm only one member of this WG<br>
<fantasai> miriam: I agree with both of you.<br>
<fantasai> miriam: so that's helpful!<br>
<fantasai> florian: I'm lost about the overall discussion, but I think @supports testing of media queries is not useful given current form of media query<br>
<heycam> fantasai: how forgiving is parsing on CQs?<br>
<fantasai> miriam: So the problem is specific to media queries, we don't have the problem with container queries right?<br>
<fantasai> emilio: it's same<br>
<fantasai> emilio: also have same problem with @supports itself<br>
<fantasai> florian: well people won't use @supports @supports<br>
<fantasai> florian: nobody will do that one so it doesn't matter<br>
<TabAtkins> Anything with `<general-enclosed>` in the grammar is forgiving in this way, and won't be good to test.<br>
<fantasai> miriam: People do wwant to know whether @supports of selectors works<br>
<fantasai> TabAtkins, yeah, but authors can't figure that out<br>
<fantasai> TabAtkins, it's totally opaque to them<br>
<TabAtkins> yeah, i'm just answering the question<br>
<fantasai> miriam: SO what's the solution that gets us there?<br>
<fantasai> florian: MQ was designed to work around the problem. When browser doesn't know how to answer it doesn't know how<br>
<fantasai> florian: [...]<br>
<fantasai> fremy: You can design the query so you get the support you want<br>
<fantasai> florian: if you want a third design where you don't know whether your design can over, this is tricky<br>
<fantasai> TabAtkins: we can let author ssolve that with custom MQ<br>
<fantasai> TabAtkins: because that's what they do today<br>
<fantasai> miriam: Does @else help? Means you can just attach a negation to the query itself<br>
<florian> s/design can over/design can hover/<br>
<fantasai> TabAtkins: top-level query is alwasy true or false, unknown is not a response<br>
<fantasai> emilio: For @media, can't you do that? Ask for a logical combination of your query and not your query<br>
<fantasai> emilio: e.g. @media hover and not hover, and that should be true on all browsers that support hover and not on ones that don't<br>
<fantasai> emilio: I mean 'or'<br>
<fantasai> emilio: so can do that with CSS already, though not beautiful<br>
<TabAtkins> (true or false) is true, (unknown or unknown) is unknown (and thus false)<br>
<TabAtkins> so yeah that works<br>
<fantasai> florian: for media features yes, but not media types<br>
<fantasai> TabAtkins: I think we have multiple ways to address the media being restrictive<br>
<fantasai> TabAtkins: I would be very sad if, though we have ways to address it, we lost ability to do anything else that doesn't have forgiving this nature<br>
<fantasai> TabAtkins: fantasai, can you let us do this as specified, if other feautres can let you figure out media queries<br>
<heycam> fantasai: I can live with it, but I really do want to hear from others in the room<br>
<fantasai> astearns: Proposed resolution is to allow testing of at-rule preludes in supports, using the prelud syntax and no nesting as yet<br>
<fantasai> florian: I suggest we include a note that things that have forgiving parsing will say yes, and it doesn't mean that they are support<br>
<heycam> fantasai: I think it will confuse a lot of people, but I understand we do want to do this for other things for which it does make sense<br>
<heycam> ... my concern for CQs is that if we have to invent a new function for say state queries, they'll ask if that's supported, and we'll say yes<br>
<fantasai> miriam: This doesn't work for the things I want it to work for<br>
<emeyer> q+<br>
<fantasai> miriam: and I agree it'll confuse people<br>
<florian> q-<br>
<astearns> ack florian<br>
<fantasai> miriam: I wonder if we can restrict it to just the things that it's useful for?<br>
<fantasai> TabAtkins: we could maybe do that, say it doesn't do anything on @media/@supports/@container<br>
<astearns> ack emeyer<br>
<fantasai> emeyer: I think Tab addressed my concern.<br>
<fantasai> emeyer: I'm concerned we're starting to cross into territory.... I agree with Elika's point that this will be confusing in these cases<br>
<fantasai> emeyer: if we restrict from those cases, then it's ok with me<br>
<fantasai> emeyer: @supports is already a bit confusing, e.g. @supports (text-decoration: blink)<br>
<fantasai> emeyer: I was concerned that we would introduce a class of problems that authors would be *much* more confused about<br>
<fantasai> emeyer: but I believe the syntax restrictions would address my concerns<br>
<fantasai> astearns: what would it address?<br>
<heycam> fantasai: anything with forgiving syntax<br>
<fantasai> TabAtkins: we have 27 at-rules ...<br>
<fantasai> florian: Anything with <general-enclosed><br>
<TabAtkins> s/27/20-something/<br>
<fantasai> florian: Alternative is if you hit <general-enclosed>, return false<br>
<fantasai> TabAtkins: that's specialized parsing<br>
<fantasai> heycam: so it's that the condition, if you use an at-rule(@media ...) it's not invalid, it's just false?<br>
<fantasai> florian: would prefer invalid, so if we figure out how to solve we can make it work<br>
<fantasai> astearns: I've lost state of proposed resolution<br>
<TabAtkins> Proposed resolution: allow testing at-rule preludes. Exclude @media, @supports, and @container from this form fo the test; they're invalid to use.<br>
<TabAtkins> (Generally, anything using <general-enclosed>, but for now it's those three.)<br>
<fantasai> florian: Can you clarify, they're invalid, does that mean they return false or they fail to parse?<br>
<fantasai> TabAtkins: they make the rule invalid<br>
<fantasai> florian: what do you mean by "the rule"<br>
<heycam> fantasai: it's as if you wrote foobar() instead of at-rule()<br>
<heycam> TabAtkins: foobar() is a false query<br>
<fantasai> astearns: We will work out what the remaining proposal is in the future for specific syntax and behavior in a summary ocomment form TabAtkins<br>
<fantasai> TabAtkins: I gave the proposed resolution, ignoring that bit about clarifying invalid<br>
<fantasai> astearns: Let's get it written out, and then come back to it<br>
<fantasai> astearns: because I've had several ppl ask that we get to Toggles!<br>
<florian> "@support at-rule(@media foo) or (display:block) { :root{ color: blue ) }" What does that do, blue or not blue?<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6966#issuecomment-1249825224 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 16 September 2022 21:18:16 UTC