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

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, <martin@auswoeger.com> 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
>
>