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

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?

 - 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
> 
> 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 <mailto: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 <mailto:jackalmage@gmail.com>> wrote:
> On Fri, Mar 18, 2016 at 11:14 AM, Paul Lewis <paul@aerotwist.com <mailto: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