- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 17 Feb 2021 18:02:28 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-contain] :root/body viewport propagation and containment`. <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-contain] :root/body viewport propagation and containment<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/5913<br> <dael> rune: encountered looking at container queries<br> <Rossen_> q<br> <Rossen_> ack faceless<br> <dael> rune: We prop the writing mode from body to root inclduing affecting used value for root element. Causes circularity if we don't say if we have containment on html don't prop to viewport. Wondering if it makes sense<br> <dael> rune: Mostly thought about writing mode, but other properties too<br> <hober> q+<br> <dael> florian: Interesting problem. What's the solution other than making contain not apply?<br> <dael> rune: Make contain not prop to viewport<br> <dael> Rossen_: Wasn't that way more impactful on compat?<br> <dael> florian: Not nec since existing content doesn't contain on body or root<br> <dael> hober: There is b/c sites exist over time and worked on by different dev. Current maintainer might want the new shiny thing and not realize site depends on viewport prop. They add this and cause a freaky action at a distance bug where other things stop working. How do you figure that out?<br> <hober> q-<br> <dael> florian: I don't want to break prop. Doesn't seem as action at a distance. Containment at root isn't meant as neutral. So not worried about action at a disance. But some of the prop is probably there because they're useful. I don't htink containment on root or body is useful so not apply seems fine<br> <jensimmons> q?<br> <dael> rune: Fine with that. Want to get rid of circularity.<br> <fantasai> for the record, propagation from root to viewport is necessary and useful; and propoagation from body is just a hack we had to introduce for compat<br> <miriam> q+<br> <fantasai> I also agree with Florian that making containment just not apply is fine, I can't think any reason why it would be useful<br> <dael> jensimmons: Agree with hober. I've already seen people teaching that best way to use container queries is to apply on root. May theoretically make no sense to use, but people will be confused by where to put containment. It's attractive to put on root<br> <dael> florian: Confused as to why, but I believe they do<br> <iank_> q+<br> <leaverou> That's so bizarre. Isn't that basically like a MQ?<br> <dael> jensimmons: If it's impossible to do something with a sensible default it becomes an exercise to teach webdev to not do something stupid. I would lean toward can we make it not terrible by default? The webdev are already saying just put it on the root and it'll work<br> <Rossen_> ack miriam<br> <Rossen_> ack iank_<br> <dael> miriam: I haven't seen people talking about jsut apply to root, but reason you might want to is for face that container queries resolve against actual font size and MQ resolve against external font size. That's one place where might be useful on the root even though MQ do most of it.<br> <dael> iank_: My personal opinion is not too worried about stopping prop. From my m emory we added prop as a convenience or a compat issue that people put writing mode on body and we didn't want to switching to orthogonal and back. This cleans it up<br> <dael> iank_: From what I've seen webdev will but it on the root and the body. Seems like an edge case.<br> <dael> iank_: I think what rune and florian propose sounds well reasoned<br> <Rossen_> q+<br> <Rossen_> ack florian<br> <Rossen_> q-<br> <miriam> +1 resolve container against root<br> <dael> florian: Two things. Containment and container query. I think if we set container query so if there's no container it resolves against root then no need to contain root. If you container query w/o container you resolve against top level and no need to apply containment to body. Would that be weird?<br> <dael> Rossen_: I was on queue to highlight there's a ton of compat in the history. Especially the tail end of body or html which are used for setting up viewport. I don't think we should minimize potential compat impact. As hober pointed out someone could adjust styles and not realize they're effecting lots of stuff<br> <florian> q+ to ask jen something<br> <dael> Rossen_: At the same time I'm hearing there are potentially use cases to have containment on body or html. Whatever the use cases are we have to understand and figure out if we need to support them and figure out what's the appropriate behavior for backwards prop. Maybe a middle ground to support backwards compat while allowing containment<br> <dael> florian: jensimmons I want to check if I understand. What I thought you said is there are people who want to do container queries in general and some of the time it'll be in a grid and sometimes it's not in anything and in those cases they don't want a MQ for non-contained cases and they set the query on the root<br> <dael> florian: If that's what you're saying I think we can work off the root to answer query. But did I miss?<br> <dael> jensimmons: Both. People will set on the root b/c used to have to set it somewhere. They're going to be lazy and stick it where they want<br> <dael> florian: Queries or jsut containment?<br> <dael> jensimmons: While using container queries. Will they combine it with a switch in writing modes, maybe. If it's really hard it might we worth the extra effort, but don't assume it's an edge case<br> <dael> florian: Making container queries on anything makes sense. If you need containment to get container queries makes sense to have containment. If you container query for anything it could work<br> <dael> jensimmons: They're going to stick a design system container where they want. Sometimes in flow, sometimes deep in dom. They won't re-write the code depending on the context<br> <dael> florian: Under that pattern makes sense to allow and the containment part appleid to root does nothing. Query when not contained asks the root. Don't have to break cycles, just go all the way up<br> <dael> jensimmons: Maybe. not sure<br> <fantasai> +1 florian<br> <Rossen_> q?<br> <miriam> +1 florian<br> <dael> florian: Need to see if it works, but general approach makes sense<br> <dael> iank_: Not sure it works, florian. Need to think. You can set...specically setting html element and youc an set properties which means will mismatch from viewport size I believe<br> <dael> iank_: So you'll have logical mismatch<br> <dael> florian: max-width on htlp element?<br> <dael> iank_: Yeah, or set a direct width. I forget exatly what applies, but you'll have a mismatch between html element and viewport<br> <dael> rune: If you spec containment on root html element such that container queries should work on thml element we'll instead use viewport?<br> <dael> florian: Yes, but iank_ has a point too<br> <dael> iank_: Yeah, I think if the choice is matching...you can set width on html element. If decision is making that resolve against viewport vs fixing containment I'm not wild about containing queries being special to one html element and having it match against viewport in one case<br> <Rossen_> q?<br> <dael> florian: I need to think. I feel like there's a shortcut but the one I mentioned earlier is wrong<br> <dael> florian: I'd like to try and find a way out of this that doesn't require breaking backwards prop of things<br> <dael> fantasai: I don't have problem breaking prop from body. It shouldn't have existed.<br> <dael> fantasai: If we want to break prop from body, jsut do it<br> <dael> myles: Not unreasonable, but this is wrong time to make that kind of big change<br> <dael> iank_: This is only breaking if we have containment applied on body. This isn't a big change. If people are worried about compat, I'm not, but we can ad a use counter<br> <dael> myles: I think jensimmons made a compelling arguement that it will not be uncommon<br> <dael> iank_: I think it's uncommon at the moment. I agree it could become common and you're opting in<br> <dael> florian: If you add a component with container queries and not paying attention to where and you don't check arabic, only english, you broke arabic<br> <dael> Rossen_: iank_ are you offering to collect some date?<br> <dael> s/date/data<br> <dael> iank_: I think I might offer rune to collect data. I also think this will only break vertical writing mode pages<br> <dael> Rossen_: We're at top of the hour. How about the following. If we can get data, great. jensimmons I'd ask you to dig out some of these examples of devs or designers talking about htis on root that would be helpful<br> <dael> jensimmons: It's in random convos and slack channels. It's not blog posts. It's the first hot take. Just set it on the root. We can teach them not to do it, but if that's the first take there's something attractive. It's a sign it's not edge case<br> <dael> florian: I think we should make it work, just aim for least breaky<br> <dael> Rossen_: It will come to a compromise so let's make sure it's the right one<br> <dael> Rossen_: We're a bit over, thanks for staying. That was great discussion<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5913#issuecomment-780741654 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 17 February 2021 18:02:31 UTC