- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 21 Apr 2021 16:40:59 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-contain] What is the migration path for Container Queries?`.
<details><summary>The full IRC log of that discussion</summary>
<dael> Topic: [css-contain] What is the migration path for Container Queries?<br>
<dael> github: https://github.com/w3c/csswg-drafts/issues/6175<br>
<dael> miriam: This issue started abotu container queries. A few potential ways authors could test for them. Using @supports and checking for something like contain-inline-size. Not entirely reliable.<br>
<dael> miriam: If browsers impl 1d separately. With @rules provide positive case but can't test for negative, lack of support<br>
<dael> miriam: Lack would be ideal here and for several other upcoming @rules<br>
<dael> miriam: That lead us to a previous proposal from Sebastian. Possibility of doing a supports check on an @rule. Adding syntax. Una summerized at end of thread. Putting @rule inside @supports<br>
<dael> emilio: Prefer dedicated function. Some @rules only valid in some parts of stylesheet. Not easy to hook into generic parsing algo.<br>
<dael> emilio: We added a selector function to test for selectors. I think a MQ like container query function would be fine with MQ inside<br>
<dael> miriam: Generically for all @rules so we don't add new funct for each rule?<br>
<dael> emilio: We don't know how future @rules will handle stuff inside them. Separate function with syntax I think is a bit more; how would you test for nesting? Just a style rule inside with random stuff? Seems, I don't know. Maybe fine<br>
<dael> miriam: Part of issue I see is this feature is the most powerful the farther away...we want this supported long before the @rules we add otherwise you lose utility<br>
<gregwhitworth> q+<br>
<dael> emilio: I think sep function is most straightforward for this. Impl more generically may be fine for rules we have. For @import would be a bit annoying. Blink, WK, and Gecko trigger import loads from parsing and it's not valid everywhere.<br>
<dael> myles: Hard to say in future we'll never add statefulness ot @rules. I don't think @rule will be valid in any context will be always true<br>
<dael> dbaron[m]: When designing @supports one intention is adding for @rules would be via a function<br>
<dael> dbaron[m]: One of the interesting things that comes up with @rules is they often have rules for how to ignore bits of syntax inside of them. I think @supports has to key off of is this @rule valid in a way that it will produce something. And @media rule with invalid MQ that would get ignored would still be supported by @support definition<br>
<dael> emilio: Good point. Invalid media lists just get parsed.<br>
<gregwhitworth> ack gregwhitworth<br>
<dael> emilio: That generic way doesn't work. PRefer specific functions for things. Maybe @-rule and take a keyword to see if browser understands in any wya<br>
<dael> dbaron[m]: Not sure how useful to check do you understand thiskeyword vs entire @rule<br>
<dael> emilio: The same way we have @supports(selector) and takes a list we'd have @supports(media and a media definition inside it that's specific on when you can consider supported.<br>
<dael> dbaron[m]: I hadn't read whole issue, but examples in comments I'm not sure what' intended by some of the examples. Multiple interpretations<br>
<dbaron[m]> The example I was commenting on was: @supports (@media (prefers-reduced-motion: reduce) {}) { ... }<br>
<dael> florian: For function emilio suggested with care dbaron[m] suggested we could do something like that if it plugs into some part of parser. @support doesn't have dedicated code path. You plug into existing machinery<br>
<dael> emilio: True.<br>
<dael> emilio: Saying we should...if you do at @rule level then what dbaron[m] says applies. @media(garbage) is valid. We should say it prses but doesn't have fallback<br>
<dael> dbaron[m]: Good reason for separate @supports for media functions. But not sure devs will understand why @rule doesn't work<br>
<dael> florian: So far I don't htink has been possible to tell UA which isn't on a media type and UA which doesn't parse<br>
<dael> emilio: Observable. If you don't parse the serialization returns not all<br>
<dael> emilio: Can't from CSS itself but you can from JS<br>
<dael> emilio: And MQ5 changes that but no one impl it yet<br>
<dael> florian: Thinking for example like features like Grid which is not CSS Grid. It's a bool and everybody returns 0 because no browser is in a terminal.<br>
<dael> emilio: I think we parse that. Same with color and other things that are matched fixed. We parse it.<br>
<dael> florian: I think prop is manigable but have to be careful along the way<br>
<dael> astearns: Prop you're referring to?<br>
<dael> florian: @supports function dedicated to media types or expressions<br>
<dael> emilio: And fix for container<br>
<dael> miriam: Was I hearing 2 approaches? @supports rule and then rule name and other is @supports expression and that's separate features?<br>
<dael> emilio: Rather then @supports rule it's a function. If it's empty you return if you support rule and if has content you parse and try and return<br>
<dael> astearns: I'm confused emilio.<br>
<dael> astearns: I agreed with miriam interpretation. Have an @rule function in an @supports which would say if you support @rule<br>
<dael> emilio: That's another option<br>
<dael> emilio: Is it useful tos ay do you support @container as is or do you want to say do you support htis container condition?<br>
<dbaron[m]> I had been thinking of things like @supports at-rule(@container ... {}) {} and @supports media-expression((width: 200px)) {}<br>
<dbaron[m]> though possibly rule() rather than at-rule()<br>
<dael> astearns: For @container do we need expression checking? Or just if @container rule?<br>
<dael> miriam: Both is useful. knowing if rule is supported at all is most useful<br>
<dael> emilio: @supports and anything else immediately returns false. We can define a syntax. When browser impl container queries the syntax can be used anywhere.<br>
<dael> emilio: A generic @supports @rule would be more generic<br>
<dael> florian: Concerned it would work at first and problems later<br>
<dael> florian: If you say I support this @rule authors will assume it works with what they want in the rule<br>
<dael> emilio: I think given we've determined want one for media expressions one for container expressions makes sense<br>
<dael> miriam: And if had container function that could accept an expression and you did @supports not-container function that would give you...?<br>
<dael> emilio: I think that should work now and browsers should do right thing now. I fyou write @supports not whatever we should parse the thing inside. We we don't we should fix that<br>
<dael> astearns: Wondering...talking about @rule function but also a media expression function and container expression function. Wonder if rule could take multi param where first is rule type and following are expressions valid in that rule<br>
<dael> emilio: Problem is you don't know what future @rules will support<br>
<dael> florian: Some have most sytnax before opening { and some it's within {<br>
<dael> dbaron[m]: And you end up inventing an additional syntax that is not what you're testing for support for<br>
<miriam> https://codepen.io/mirisuzanne/pen/VwPVpeK<br>
<dael> myles: IN @fontface we added descriptors. Would htis prop allow authors to determine if ascent-override is supported?<br>
<dael> emilio: There's a good question about if existing syteax should support parsing descriptors<br>
<dael> dbaron[m]: Could add a descriptor function. Or we could say they're valid in there b/c similar to prop<br>
<oriol> miriam, you have a typo, it's @supports, not @support. Then it's green<br>
<dael> florian: Should keep them separate. A bit of name collision<br>
<dael> emilio: Right. We can have function that takes fontface descriptor. Proposal as is doens't address but trivial to add<br>
<dael> florian: Descriptor with first param as a rule and second is descriptor with same syntax as properties?<br>
<dael> emilio: Resonable. Or add fontface-descriptor<br>
<dael> myles: Don't need to design new feature<br>
<fantasai> s/feature/feature on the call/<br>
<dael> astearns: Yes, we're far afield from original question. But if want to do right for container and container expressions need to consider how would look for other @rules<br>
<dael> emilio: Perhaps go to issue and flesh this out for next week<br>
<dael> emilio: Proposing syntax for container and media; precise syntax<br>
<dael> astearns: For a function that tells you if @rule is supported and other to tell you if expressions are supported<br>
<dael> emilio: Yeah. Not clear if you want the is the @rule supported at all. Maybe footgun. Maybe just media, container, fontface, and so on<br>
<dael> astearns: Okay<br>
<dael> miriam: Works for me<br>
<dael> astearns: Additional comments?<br>
<dael> plinss: Random thought from miriam original comment on negative case. Generic @rule that's @else which is only for if previous @rule doens't apply<br>
<dael> fantasai: There's an issue on that<br>
<dael> TabAtkins: On the generic when/else. not the else/if you can tack to anything<br>
<dael> plinss: This would be @container else<br>
<dael> florian: Else proposed would be @support and @media but not designed to work on any. @fontface else isn't clear<br>
<dael> plinss: Sure. Some it doesn't make sense for. It could be openended. Don't have to disallow but it would never apply for @fontface unless browser doesn't support it<br>
<dael> astearns: I'll take action to find the else issue and point it to this one<br>
<dael> astearns: Anything else on this?<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6175#issuecomment-824203423 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 21 April 2021 16:41:03 UTC