[css-containment] Splitting size into width and height

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[css-containment] Splitting size into width and height

Martin Auswöger
Hello,

the current CSS containment draft defines the “size containment” and mentions, as a possible use case, JS libraries implementing the “container query” concept. I wrote [such a library][1] and think it would be very helpful if size containment could be enabled for one dimension only so that the other dimension can still be auto-sized.

Tab Atkins already wrote something about this here on [16 Mar 2016][2]
> It's also useful for userland implementations of "container queries" to prevent loops, especially if we can activate it *solely* for the inline axis (letting the block axis still auto-size based on children).

There was also a discussion about container queries and size containment at [ResponsiveImagesCG/container-queries#3][3].

Containment could get changed to:

contain: none | strict | content | [ layout || style || paint || [ size | [ width || height ] ] ]

There may be better names for width/height like size-x/size-y or inline-size/block-size but I think width/height ist more obvious for CSS authors.

Does this make sense, or could it have any negative implications?

Martin

[1]: https://github.com/ausi/cq-prolyfill
[2]: https://lists.w3.org/Archives/Public/www-style/2016Mar/0245.html
[3]: https://github.com/ResponsiveImagesCG/container-queries/issues/3#issuecomment-185951645

Reply | Threaded
Open this post in threaded view
|

Re: [css-containment] Splitting size into width and height

Ojan Vafai-2

The only potential downside I see is that it makes for more values for web authors to make sense of and the implications of the current values is already kind of not obvious. I expect the vast majority of usage here to be contain:contents.

Keep in mind that setting any definite/fixed width/height will get you the benefits of width/height containment even without using the contain property. The default width value already causes containment for most display types. The default height value doesn't, but usually you don't want both height:auto and containment. 

In either case, if other browsers would implement this, I expect chrome would as well. But we believe the vast majority of needs are met by the strict and contents values. More developer demand would of course change our opinion on that point. :)

Do you have a case of wanting width/height containment but not wanting to also set a definite width/height value?


On Mon, 20 Jun 2016, 08:50 Martin Auswöger, <[hidden email]> wrote:
Hello,

the current CSS containment draft defines the “size containment” and mentions, as a possible use case, JS libraries implementing the “container query” concept. I wrote [such a library][1] and think it would be very helpful if size containment could be enabled for one dimension only so that the other dimension can still be auto-sized.

Tab Atkins already wrote something about this here on [16 Mar 2016][2]
> It's also useful for userland implementations of "container queries" to prevent loops, especially if we can activate it *solely* for the inline axis (letting the block axis still auto-size based on children).

There was also a discussion about container queries and size containment at [ResponsiveImagesCG/container-queries#3][3].

Containment could get changed to:

contain: none | strict | content | [ layout || style || paint || [ size | [ width || height ] ] ]

There may be better names for width/height like size-x/size-y or inline-size/block-size but I think width/height ist more obvious for CSS authors.

Does this make sense, or could it have any negative implications?

Martin

[1]: https://github.com/ausi/cq-prolyfill
[2]: https://lists.w3.org/Archives/Public/www-style/2016Mar/0245.html
[3]: https://github.com/ResponsiveImagesCG/container-queries/issues/3#issuecomment-185951645

Reply | Threaded
Open this post in threaded view
|

Re: [css-containment] Splitting size into width and height

Martin Auswöger
> Do you have a case of wanting width/height containment but not wanting to also set a definite width/height value?

Yes, I think this would be the case for most container query use cases. Usually you want a container with a width that is independent of its descendants and a height that depends on the descendants. This way you can query the width of the container and style its children accordingly without the risk of creating loops.

The problem with the width and height properties is, that they don’t define alone if the size is descendants-dependent or not. E.g. `display: block; width: auto` is usually independent of descendants but not if it’s inside a `float: left` or `display: flex` element. Even a definite size like `width: 100px` could get descendants-dependent if it’s for example inside a `display: flex` element and has `flex-basis: 0%`. The rules get very complex and hard to detect, whereas checking if `contain: width` is set on a specific element would be very easy (via JavaScript).


Reply | Threaded
Open this post in threaded view
|

Re: [css-containment] Splitting size into width and height

Tab Atkins Jr.
In reply to this post by Martin Auswöger
On Sat, Jun 18, 2016 at 9:12 AM, Martin Auswöger <[hidden email]> wrote:

> Hello,
>
> the current CSS containment draft defines the “size containment” and mentions, as a possible use case, JS libraries implementing the “container query” concept. I wrote [such a library][1] and think it would be very helpful if size containment could be enabled for one dimension only so that the other dimension can still be auto-sized.
>
> Tab Atkins already wrote something about this here on [16 Mar 2016][2]
>> It's also useful for userland implementations of "container queries" to prevent loops, especially if we can activate it *solely* for the inline axis (letting the block axis still auto-size based on children).
>
> There was also a discussion about container queries and size containment at [ResponsiveImagesCG/container-queries#3][3].
>
> Containment could get changed to:
>
> contain: none | strict | content | [ layout || style || paint || [ size | [ width || height ] ] ]
>
> There may be better names for width/height like size-x/size-y or inline-size/block-size but I think width/height ist more obvious for CSS authors.
>
> Does this make sense, or could it have any negative implications?

Yeah, I think we should have the ability to say that only one axis
gets size containment (as I said in your quote of me), but I'm also
happy to let containment percolate out a bit first. We can expand
"size" later safely.

~TJ