- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 19 Jan 2022 17:55:55 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `feature detection for descriptors`, and agreed to the following:
* ``RESOLVED: Add an `at-rule` function with syntax `at-rule(@keyword)` or `at-rule(@keyword; descriptor: value)` ``
<details><summary>The full IRC log of that discussion</summary>
<emilio> topic: feature detection for descriptors<br>
<emilio> TabAtkins: seems reasonable to ask for this given we can do it for properties<br>
<emilio> ... as @rules grow you might want to be able to test for given descriptors<br>
<emilio> ... there's a suggestion that we add a new @supports query to test for descriptors<br>
<lea> github: https://github.com/w3c/csswg-drafts/issues/2463<br>
<emilio> ... I'd describe the two that I think we should add<br>
<emilio> ... and lea has other ideas<br>
<emilio> ... I think we should test for general @-rule support<br>
<emilio> ... so "can you identify this rule at all"<br>
<emilio> ... the other one should be a more complex one for testing for a whole @rule<br>
<emilio> q+<br>
<TabAtkins> @supports (@rule) {...}<br>
<TabAtkins> and @supports (@rule { desc: value; }) {...}<br>
<fantasai> TabAtkins was summarizing https://github.com/w3c/csswg-drafts/issues/2463#issuecomment-1015709662 right?<br>
<TabAtkins> yes<br>
<emilio> lea: I think the only additional thing I proposed is that we shouldn't have to add random descriptors to see if the browser supports particular descriptors or what not<br>
<emilio> ... so test for support for e.g. @property or so<br>
<chris> q+<br>
<TabAtkins> emilio: Regarding testing the whole rule<br>
<oriol> q+<br>
<Rossen_> ack emilio<br>
<TabAtkins> emilio: It's a bit weird, because we don't track parse errors, we just drop<br>
<TabAtkins> emilio: We could od that potentially, but it goes against th eprinciple<br>
<TabAtkins> q+<br>
<TabAtkins> emilio: I think it would be nicer to do somethign else, but not sure what else could be<br>
<TabAtkins> emilio: Don't have a generic idea for it<br>
<TabAtkins> emilio: Like would great for `font-face-descriptor(desc: value)` but then you'd need it for each<br>
<TabAtkins> emilio: Just scares me if it gets out of sync<br>
<emilio> chris: wanted to check where we are in nested at rules<br>
<Rossen_> ack chris<br>
<fantasai> emilio: Another related concern, some rules are related<br>
<fantasai> emilio: so if you parse an at-rule in an @supports block ...<br>
<fantasai> emilio: should we consider position in the style sheet?<br>
<Rossen_> ack oriol<br>
<emilio> ack oriol<br>
<emilio> oriol: it seems strange to me the including-the-whole-at-rule<br>
<emilio> ... because parens would accept a weird set of syntax<br>
<emilio> ... and this seems a bit inconsistent / confusing to authors to me<br>
<TabAtkins> (I'm fine with an `at-rule()` function, fwiw.)<br>
<emilio> ... because they might want to test for style rules<br>
<emilio> ... but we're not supporting that, so I'd prefer another function<br>
<emilio> ... or an option for testing general rules that could be an at-rule() or general rule<br>
<emilio> ... but mixing some but not all rules, and also property-declarations in parens would be a strange mix<br>
<Rossen_> ack TabAtkins<br>
<emilio> TabAtkins: emilio's point about the whole rule testing is a very reasonable point and I don't want to do this if it requires special cases<br>
<emilio> ... I'd like to instrument the existing parser if possible<br>
<fantasai> emilio: Even with instrumentation, it can still get out of sync<br>
<fantasai> emilio: e.g. someone forgets to propagate the error<br>
<fantasai> emilio: so even if set just a boolean that indicates parser error<br>
<fantasai> emilio: if don't set it at the right time, is a problem<br>
<fantasai> emilio: It wouldn't be a whole new parser, just concerned about sync<br>
<emilio> TabAtkins: connected to that, there's chris' question about nesting<br>
<emilio> ... if you have per-at-rule descriptor function then you don't get nested at-rules for free<br>
<emilio> ... the other question was about context<br>
<emilio> ... I'd say we should specify what the parsing context is for this<br>
<emilio> ... which would be the generic top-level stylesheet context, so @import would fail<br>
<emilio> ... and re oriol's point I'm totally fine with `at-rule()` or something if you think it's less fair<br>
<oriol> Yeah it think that's better<br>
<Rossen_> ack dbaron<br>
<emilio> dbaron: I think when I wrote the @supports proposal the way I had envisioned extending them is that we'd add new functions for other points where CSS drops things<br>
<emilio> ... so at the point where the CSS parser says "oh, that is invalid so we drop it as a unit", that seems sensible to add a function for<br>
<emilio> ... and I think it's a bit weird to put a whole rule inside @supports<br>
<TabAtkins> q+<br>
<emilio> ... that said I think TabAtkins' argument about nesting is interesting, because the approach I was thinking of at the time doesn't allow you to test for such things<br>
<emilio> ... so I have mixed feelings about it<br>
<Rossen_> ack fantasai<br>
<emilio> fantasai: regarding the TabAtkins' generic top-level context I think that'd be confusing to authors, I think it'd be more understandable and useful to authors if we allowed both that or anything that's in the prelude, so that e.g. @import would count as supported<br>
<emilio> ... I think it'd be less confusing to authors<br>
<emilio> ... and I can see use cases for doing that if you want to do something conditional in whether some extended at-import syntax is supported<br>
<emilio> ... I also wanted to say about dbaron's comment that it would be better to have the nested syntax rather than having many functions<br>
<emilio> ... I'd prefer parenthesis rather than a function, I think it'd be a little bit cleaner and easier to type<br>
<emilio> q+<br>
<TabAtkins> @supports at-rule(@foo) {...} and @supports at-rule(@foo, desc: value) {...}<br>
<emilio> ack TabAtkins<br>
<Rossen_> ack TabAtkins<br>
<emilio> TabAtkins: thanks dbaron for all that context. If we follow those premises we also avoid emilio's concerns. In that context perhaps we could do something like what I typed above in the chat<br>
<emilio> ... it doesn't address nesting right now but we can extend it if needed<br>
<fantasai> s/many functions/many custom functions per at-rule/<br>
<emilio> ... we also don't and probably won't have many at-rules that are inconsistently nested<br>
<faceless> Surely @supports (@import) should always fail, as @import must be the first rule? So if you precede it with @supports, it's not valid?<br>
<miriam> q+<br>
<fantasai> faceless, I don't think @supports queries should be sensitive to position<br>
<Rossen_> ack emilio<br>
<lea> faceless: is there a use case for @supports(@import)? Literally every browser supports @import, no?<br>
<fantasai> emilio: @supports(@import) { } and then not put an @import inside<br>
<TabAtkins> Not as a positive test, as a negative test.<br>
<fantasai> TabAtkins: My proposal is not parsing, just is this at-rule in your list of recognize at-rules<br>
<fantasai> emilio: fantasai it might be useful to test e.g. @supports(@import "" layer) or something<br>
<fantasai> emilio: though for layer you could check to @layer<br>
<fantasai> emilio: I think having a generic at-rule() function is better than having function per at-rule<br>
<fantasai> TabAtkins: The downside is it wouldn't allow testing the prelude of an at-rule<br>
<Rossen_> ack miriam<br>
<emilio> miriam: prelude seem important for several things like layers and container<br>
<fantasai> miriam: That was my question, because preludes seem important for many things, such as @layer and @container<br>
<emilio> ... so it seems odd to leave it<br>
<emilio> fantasai: I see that at-rule() as an improvement to having a function per at-rule<br>
<emilio> ... but I don't see how that is better than just dropping the whole css syntax<br>
<TabAtkins> If we wanted to add it, could have the form `at-rule(@foo prelude stuff)`; when there's >1 token there we test full prelude parsing<br>
<emilio> ... it'd cover handling the prelude / descriptors / nested at-rules / etc<br>
<emilio> ... so I don't understand why we'd go for the function rather than the proposal that was on the issue<br>
<emilio> TabAtkins: emilio and dbaron explained why that wasn't great<br>
<emilio> ... you'd need to detect whether there's a parse error somewhere in a rule needs intrumenting the parser<br>
<emilio> ... whether testing whether something is dropped entirely or not is easy and can be done with no possibility of missing things<br>
<Rossen_> q?<br>
<Rossen_> ack fantasai<br>
<emilio> ... because we definitely drop things that are invalid and is detectable, but detecting whether an inner descriptor failed to parse inside an at-rule requires special-casing<br>
<emilio> Rossen: does that answer your question elika?<br>
<emilio> fantasai: yes<br>
<TabAtkins> @supports at-rule(@foo) {...} and @supports at-rule(@foo, desc: value) {...}<br>
<emilio> TabAtkins: proposal is having the at-rule function with two syntax variants: `at-rule(@keyword)` and `at-rule(@keyword, descriptor)`<br>
<emilio> fantasai: not against that but I have a question about how do we extend to the prelude<br>
<emilio> TabAtkins: posted that up as well, we could have it drop the whole prelude in there or something<br>
<emilio> fantasai: but prelude might include commas<br>
<emilio> ... if you want something not in the prelude you're going to need a semi-colon<br>
<lea> what about descriptor values? at-rule(@keyword, descriptor, value)?<br>
<emilio> TabAtkins: alright let's use semi-colons<br>
<fantasai> emilio: Meant to write descriptor:value<br>
<emilio> lea: would there be a way to test for @rule <name> or so?<br>
<emilio> TabAtkins: that's the prelude extension we were discussing above<br>
<TabAtkins> at-rule(@keyword; desc:value)<br>
<emilio> dbaron: so to clarify you wouldn't extend it to put the whole at-rule inside right?<br>
<emilio> TabAtkins: right, or we just drop it and if we drop descriptors inside then it'd test true<br>
<emilio> ... I think we should resolve on the keyword and descriptor variants and we can extend to support the whole prelude<br>
<emilio> RESOLVED: Add an `at-rule` function with syntax `at-rule(@keyword)` or `at-rule(@keyword; descriptor: value)`<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2463#issuecomment-1016720310 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 19 January 2022 17:55:57 UTC