W3C home > Mailing lists > Public > public-css-archive@w3.org > May 2021

Re: [csswg-drafts] [css-contain] What is the migration path for Container Queries? (#6175)

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Wed, 12 May 2021 16:52:57 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-839937577-1620838376-sysbot+gh@w3.org>
The CSS Working Group just discussed `[css-contain] What is the migration path for Container Queries?`, and agreed to the following:

* `RESOLVED: Have unknown @supports expressions evaluate to false for all @support rules`
* `RESOLVED: Create a container function that can test if @supports checks for a particular container query`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: [css-contain] What is the migration path for Container Queries?<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/6175<br>
&lt;dael> miriam: Talked a couple weeks ago. confusion on intent. Going for @supports should always treat unknowns as unsupported<br>
&lt;dael> miriam: Allows new funt and testin work backward compat<br>
&lt;dael> miriam: 2 resolutions. 1) any unknown supports eval as unsupported 2) add container funt for testing support of specific container conditions<br>
&lt;dael> florian: When you say treat unknown as unsupported at top level,  you mean immediately?<br>
&lt;dael> miriam: Yeah<br>
&lt;dael> miriam: Being able to negate it and have it return true is essential here<br>
&lt;dael> TabAtkins: Good with this<br>
&lt;dael> astearns: Changing behavior for all supports rules?<br>
&lt;dael> miriam: Right now not interop on this<br>
&lt;dael> miriam: Chart in the thread of current handling<br>
&lt;dael> astearns: Thanks<br>
&lt;dael> TabAtkins: Spec is unclear. Does not define. Was intended to be different, but Nina convinced me this is better<br>
&lt;dael> florian: Didn't we have prop for unified syntax for combo of media and supprot queries?<br>
&lt;dael> TabAtkins: That's my when/else proposal. We'll deal with that when it comes up<br>
&lt;dael> florian: Okay. Might be a problem, but not as important as containers<br>
&lt;dael> astearns: Prop: Unknown at-supports evaluate to false and add that to spec for all supports rules<br>
&lt;dael> florian: For this use case it's right. Will it always be or should we specialize to supports query for containers?<br>
&lt;dael> miriam: I can't see situation for other behavior. Any new type of check we add to at-supports to determine if supported need it previously returning false<br>
&lt;dael> florian: Add new feature and query together, yes. Support syntax for things that predeated abaility to detect then no.<br>
&lt;dael> TabAtkins: I think consider future longer then past. A supports query moving forward that you don't understand is for a new feature you don't understand<br>
&lt;dael> astearns: A bit concerned we haven't run across this lack of interop. Are people not using not was supports?<br>
&lt;dael> miriam: Ran into this with selector<br>
&lt;dael> florian: With selectors, do we not want opposite behavior?<br>
&lt;dael> astearns: In this case opposite as @supports nad @supports not eval to unknown<br>
&lt;dael> florian: An unknown stays unknown until top at which point it becomes false<br>
&lt;dael> miriam: Why would we want that?<br>
&lt;astearns> +1 to miriam<br>
&lt;dael> TabAtkins: Same as a feature. If you don't understand enough to evaluate you don't understand to use.<br>
&lt;dael> florian: Okay. Maybe I'm not thinking correctly. Defer to TabAtkins<br>
&lt;dael> astearns: Prop: Have unknown @supports expressions evaliate to false for all @support rules<br>
&lt;dael> RESOLVED: Have unknown @supports expressions evaluate to false for all @support rules<br>
&lt;dael> astearns: Do we also need to resolve for the @supports for specific features<br>
&lt;dael> miriam: Looking for a container function in @supports that accepts container query query conditionals<br>
&lt;dael> astearns: Is it the full syntax? Or a subset?<br>
&lt;dael> miriam: I think it should accept any...hmmm<br>
&lt;dael> miriam: Maybe it should be one query at a time and you can string together multiples of the function<br>
&lt;dael> miriam: Accepts single conditional<br>
&lt;dael> astearns: Had not thought threw this. Possibel we'll have new things you can add to funct over time such that an instance may or not eval based on state of impl?<br>
&lt;dael> miriam: I expect we will add additional feature queries over time<br>
&lt;dael> astearns: That seems to me argument to string together multiples. Maybe. maybe not<br>
&lt;dael> miriam: Makes sense and makes simpliest case simplier. @container and a singe query. Makes sense to me<br>
&lt;dael> astearns: Other opinions?<br>
&lt;dael> astearns: Prop: Create a container function that can test if @supports checks for a particular container query<br>
&lt;dael> astearns: Objections?<br>
&lt;dael> RESOLVED: Create a container function that can test if @supports checks for a particular container query<br>
&lt;dael> astearns: I expect once this is specced we'll have more questions<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-839937577 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 12 May 2021 16:53:00 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:27:23 UTC