W3C home > Mailing lists > Public > public-css-archive@w3.org > April 2017

Re: [csswg-drafts] [css-contain-1] do we need layout containment in a single dimension to enable container queries?

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Wed, 19 Apr 2017 08:05:58 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-295152488-1492589157-sysbot+gh@w3.org>
The CSS Working Group just discussed , and agreed to the following resolutions:

```
RESOLVED: Level 2
```

<details><summary>The full IRC log of that discussion</summary>

```
<fantasai> Topic:
<Florian> github topic: https://github.com/w3c/csswg-drafts/issues/1031
<fantasai> github topic: https://github.com/w3c/csswg-drafts/issues/1031
<fantasai> Florian: Next one from dbaron...
<fantasai> dbaron: This one is a big issue
<fantasai> dbaron: One of the things that a bunch of web devs really want is what they call "container queries"
<fantasai> dbaron: which basically addresses the sue case of teams that develop widgets or modules that are part of a bigger page
<fantasai> dbaron: Their developing some markup and script and whatever that gets included within a bigger page, and it will have some size
<fantasai> dbaron: The bigger page might use meida queries to e.g. switch from 3 columns to 2 colums, and widgte gets bigger though viewport got smaller
<fantasai> dbaron: If you're implementing the widget, you want to respond to the size that the widget is, not the size of the viewport
<fantasai> dbaron: Bunch of ppl want container queries that actually work, rather than do what ppl do right now which is do layout, flush, and set styles based on that
<fantasai> dbaron: Seems to me it should have some relation to containment
<fantasai> dbaron: that is, ability to do container queries should depend on some kind of ocntainment so that your insides dont depend on your outsides which depend on your insidees
<fantasai> dbaron: The next point is that sometime sppl want to do container query on their width, but have an autho height
<fantasai> dbaron: So, was thinking we want to have layout containment in only one dimension
<fantasai> dbaron: Beyond that haven't thought about it, so this is a "please design me a feature" issue
<fantasai> dbaron: This seems like a relatively high priority feature because ppl do this a lot, and do it by doing flush-restyle loops
<fantasai> Florian: If theyr'e willing to go that far, using 2D size containment is good, set it and then reset your height after you do layout
<fantasai> dbaron: Get ppl doing it for multiple parts of the page, so cycles multiple times
<fantasai> fantasai: why not just have -x -y keywords?
<fantasai> TabAtkins: Hard to define what htat means
<fantasai> eae: Maybe sets wrong expectations, that you wouldn't get same perf benefits
<fantasai> TabAtkins: True, but you do get the benefit that when your'e using resize observer you get predictable behavior and not loops
<fantasai> Florian: Seems like level 2, esp we don't have proposal yet
<fantasai> TabAtkins: This plus resize observer plus custom at-rules, I'm hoping will allow solving this use case
<fantasai> TabAtkins: Been my plan for like 10 years
<fantasai> s/10/2/
<fantasai> RESOLVED: Level 2
```
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1031#issuecomment-295152488 using your GitHub account
Received on Wednesday, 19 April 2017 08:06:09 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:11 UTC