- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 05 Jan 2023 00:26:14 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-contain-3] Inconsistent handling of known and unknown features jeopardizes backward compatibility`, and agreed to the following: * `RESOLVED: Go with option 1 and get implementor feedback` <details><summary>The full IRC log of that discussion</summary> <dael> miriam: The issue is that currently when we're looking for a container to resolve queries against we look for nearest ancestor of appropriate type<br> <dael> miriam: if containers we find don't have type, don't find anything, we return false<br> <dael> miriam: however if you use a general enclosed unrecognized type resolve as unknown<br> <dael> miriam: At some point unrecognized becomes recognized and instead of resolving unknown we keep looking for more containers or resolve false<br> <dael> miriam: Discrepency between feature we don't understand and features that are not supported on that type is different. Could be a problem down the road<br> <dael> miriam: Two approaches we could take. One is complex about OR logic where when there is an or we resolve 2 sides separately or only need one match. That's getting a bit clever<br> <dael> miriam: Other is encount for general enclosed in the selection processes for account for it in container selection<br> <dael> TabAtkins: not super clear on precise behavior. If you have query height or width today and evaluate on inline-size it doesn't evaluate to true?<br> <dael> TabAtkins: b/c width would be correct?<br> <dael> miriam: Doesn't evaluate at all. Looks at two types and says this container can't answer question and it looks for a different container<br> <dael> TabAtkins: Yeaaah. I suspect that's what we want to fix b/c makes ORs not an OR<br> <dael> miriam: That would be option 1 to account for it in OR logic<br> <dael> TabAtkins: Only implication is right now can scan container query and know what will be required for it to be valid so you can filter more agressively. Is that intention?<br> <dael> miriam: Intention is selection process is automated. Before it was manual<br> <dael> miriam: I don't know if there's problems from impl side on splitting the container selection logic on OR<br> <dael> fantasai: I don't think there would be<br> <dael> TabAtkins: Not being an impl expert, I'm going to say probably not<br> <dael> TabAtkins: Go with that pending obj from implementations?<br> <fantasai> +1<br> <dael> astearns: Yep unless there are other opinions?<br> <dael> astearns: Prop: Go with option 1 and get implementor feedback<br> <dael> astearns: Obj?<br> <dael> RESOLVED: Go with option 1 and get implementor feedback<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7551#issuecomment-1371579460 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 5 January 2023 00:26:16 UTC