- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 26 May 2021 17:01:12 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-contain] Should there be a new syntax for establishing queryable containers?`, and agreed to the following: * `RESOLVED: Container queries are triggered by independent property (name to be bikeshed)` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-contain] Should there be a new syntax for establishing queryable containers?<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/6174<br> <dael> miriam: In the first prop for container queries and in chrome prototype we've been using establishment of containment.<br> <dael> miriam: Been concern about that from different angles. Interest in more explicit syntax. Looking at new values for contain which felt cluttered or adding a new property which is what I'm proposing<br> <bkardell_> miriam: could you summarize what the 'from a lot of angles' concerns about current were?<br> <dael> miriam: For now calling it container property. Don't know if names are too similar but it's the name of the feature.<br> <dael> miriam: Idea is this would trigger containment on the backend. I think we have precident for that. This would allow us to flesh out syntax where author only says what they hope to be able to query on a container and then containment happens on the backend. They just say i want to query inline dimension and containment is provided<br> <dael> miriam: New path for can we have named containers. Can give containers a custom ident. That's a separate issue<br> <florian> q+<br> <dael> miriam: Can resolve we like this general direction. Can resolve to move forward with container for now. Also are we interested in pursuing named containers more<br> <Rossen_> ack fantasai<br> <dael> fantasai: Question about should it be a keyword in container or separate. Cluttering the syntax might get complicated as you outlined. We can do things like query is a keyword and add other keywords<br> <dael> fantasai: Question is should they cascade independent or together and that decides if you want separate or same property. Not sure which way, but that's they question you need to ask. Cascade to combine or cascade to override.<br> <dael> fantasai: It's less about what is the right syntax and more about cascading question<br> <dael> fantasai: If keyword is query perhaps property should be query since contain and container together might be confusing.<br> <fremy> Good point. Do we want it to be easy to have `contain:paint` and `contain:container` override each other?<br> <Rossen_> ack florian<br> <fantasai> s/right syntax/prettier syntax/<br> <bkardell_> q+<br> <dael> florian: From cascading argument I suspect nice to have separate. contain is performance and container queries is not.<br> <dael> florian: I was wondering, do you expect you will need to set very different types of containment depending on what you need to query about? If yes, argument to sep the two. If regardless of what they want to query it's pretty much set all containments it's less to separate<br> <dael> miriam: There is talk about types of query that wouldn't require as much or any containment. None is sense of it's outside of element doing the query. That is another reason to add as separate<br> <Rossen_> ack bkardell_<br> <dael> bkardell_: I think florian and miriam covered my point. I support htat containers is a separate concept. Currently we don't know everything will require containment as defined in containment.<br> <dael> bkardell_: Other point is first from florian that containment is used for performance which is a separate concern and don't want to step on one or another<br> <dael> fremy: I was going to say the same thing<br> <dael> Rossen_: Any other feedback?<br> <dael> Rossen_: Prop path...can miriam or fantasai summarize?<br> <dael> Rossen_: What do we want WG to resolve on?<br> <dael> fantasai: Prop: Container queries are triggered by independant property<br> <dael> bkardell_: Still in contain?<br> <dael> florian: In spec, yes. Mechanics will probably effect used but not computed<br> <dael> bkardell_: Just meant where does text go<br> <fantasai> s/computed/computed value of contain property/<br> <dael> florian: Need to bikeshed spec text.<br> <bkardell_> interesting!<br> <dael> fantasai: Prop: Name of property is query rather than container so we don't have contain and container. Either way we go independent prop<br> <bkardell_> I think miriam also was doing some polling on bikeshedding another name somewhere?<br> <dael> Rossen_: Prop: Container queries are triggered by independent property (name to be bikeshed)<br> <dael> RESOLVED: Container queries are triggered by independent property (name to be bikeshed)<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6174#issuecomment-848948519 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 26 May 2021 17:01:15 UTC