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