W3C home > Mailing lists > Public > www-style@w3.org > June 2016

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 20 Jun 2016 12:17:01 -0700
Message-ID: <CAAWBYDAN7fEE0EtTUOCF4mVsYHPes5kKtnx4KFpMBV-xxr-n4g@mail.gmail.com>
To: Martin Auswöger <martin@auswoeger.com>
Cc: www-style list <www-style@w3.org>
On Sat, Jun 18, 2016 at 9:12 AM, 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?

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
Received on Monday, 20 June 2016 19:17:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:47 UTC