Re: [css-containment] Splitting the "sizing" part from "layout" containment

On Mon, Mar 21, 2016 at 12:06 PM, Ojan Vafai <> wrote:

> On Mon, Mar 21, 2016 at 2:29 AM Florian Rivoal <> wrote:
>> Splitting sizing from layout makes sense to me.
>> As for one property vs two, I think the key question is, as it often is
>> when we run into this debate, do these two things benefit from the ability
>> to cascade separately.
>> If you're using them on (web) components, I don't think there's a
>> benefit. Which type of containing might be different on different
>> components, but for each component you'll want to decide on all 4 aspects
>> of containment.
>> On the other hand, if you do want to use the containments other than
>> sizing in a heavy handed way all across your page, and separately add
>> sizing containment without changing the other aspects of containment, then
>> it makes sense.
>> Would you? I can see adding all-but-sizing all over the place, and
>> specifying some-specific-combo-which-may-include-sizing on components in
>> the same page. But would you do all-but-sizing all over the place, and ADD
>> sizing without wanting to change whatever the rest was in specific parts?
>> If the answer's yes, then two properties are better, but what's the use
>> case?
> This seems extremely rare to me. I think the 99.99% use case is to use one
> of strict or strict-compatible. Hence my thinking that we should have a
> single property.
>>  - Florian
>> On Mar 19, 2016, at 09:50, Ojan Vafai <> wrote:
>> There are two important use-cases here:
>> 1. A simple way to get strong containment without needing to understand
>> the intricacies of the platform and of each vendor's implementation. This
>> is "style layout paint size".
>> 2. A simple way to get soft containment that can be used broadly (e.g.
>> via "* { contain: strict }"). This is "style layout paint".
>> #1 is an extension of #2 and I think it should read that way. Also, it's
>> really critical that #1 be very simple. It's just so draconian that it
>> can't be used as the 90% use-case. But it's really critical for that other
>> 10%.
>> It seems to me that we just have a naming problem here, but that we can
>> still have a single property. I think "strict" is a good name for #1. We
>> just need to make a name for #2 that sounds like the pre-cursor to #1.
>> Here's a few proposals:
>> a) strictish
>> b) strictable
>> c) strict-candidate
>> d) pre-strict
>> How about e) content? I'm not a huge fan of implying strict when we're
not strict.

FWIW, I agree that we should have a property for both strict and
whatever-we-call-strict-without-size. I think Ojan is right that one or the
other will work well for the majority of use cases.

>> I prefer (c), but would be happier with any of these than splitting this
>> up into two properties.
>> On Fri, Mar 18, 2016 at 11:24 AM Paul Lewis <> wrote:
>>> Thanks for the clarification! SGTM.
>>> Seems like a good addition irrespective of containment. Mainly I'm happy
>>> if strict doesn't require explicit widths and heights. If there's a way to
>>> ensure that independently then yay.
>>> On Fri, 18 Mar 2016, 18:18 Tab Atkins Jr., <> wrote:
>>>> On Fri, Mar 18, 2016 at 11:14 AM, Paul Lewis <>
>>>> wrote:
>>>> > If we go with a separate property then that restores the clarity of
>>>> contain,
>>>> > which is good.
>>>> >
>>>> > The concern I would have then is what this other property looks like.
>>>> I
>>>> > guess it comes like flex properties, which only apply when the parent
>>>> is
>>>> > display: flex?
>>>> >
>>>> > So I guess, yeah, if a developer sets this additional property along
>>>> with
>>>> > width and height (does it need both?) then there's an extra constraint
>>>> > applied, but for the main case "strict-ish" just got promoted to
>>>> "strict"
>>>> > and we make this sizing property, in conjunction with the other, the
>>>> "super
>>>> > strict" option? :)
>>>> Nah, the idea is that you'd have something like "height-foo: auto |
>>>> pretend-you-are-empty;" (all names subject to change, obviously).  It
>>>> would be completely disconnected from 'contain', and it applies to all
>>>> elements at all times.  If you set it to "pretend-you-are-empty", then
>>>> you need to either provide a value for 'height' as well, or your
>>>> element will break in an obvious way, as it immediately collapses to
>>>> zero height.  Similar for 'width'.
>>>> ~TJ

Received on Wednesday, 23 March 2016 20:02:43 UTC