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

Agree! I like "content" and "strict" for "layout paint style" and "layout
paint style size" respectively.

On Wed, 23 Mar 2016, 05:06 Ojan Vafai, <ojan@chromium.org> wrote:

> On Tue, Mar 22, 2016 at 1:26 PM Levi Weintraub <leviw@chromium.org> wrote:
>
>> On Mon, Mar 21, 2016 at 12:06 PM, Ojan Vafai <ojan@chromium.org> wrote:
>>
>>>
>>>
>>> On Mon, Mar 21, 2016 at 2:29 AM Florian Rivoal <florian@rivoal.net>
>>> 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 <ojan@chromium.org> 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.
>>
>
> I like it! It's about how it contains all it's content whereas strict is
> that it contains all it's content *and* it doesn't affect stuff around it
> when it's content changes.
>
>
>> 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 <paul@aerotwist.com> 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., <jackalmage@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> On Fri, Mar 18, 2016 at 11:14 AM, Paul Lewis <paul@aerotwist.com>
>>>>>> 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
>>>>>>
>>>>>
>>>>