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

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? :)

On Fri, 18 Mar 2016, 18:07 Tab Atkins Jr., <> wrote:

> On Fri, Mar 18, 2016 at 10:46 AM, Paul Lewis <> wrote:
> > Hehe yeah, that's fine. I think what I'm driving at is that both "strict"
> > and -- fair enough -- "all" both imply that 4/4 are accounted for. I
> wonder
> > if we need to use a different keyword for 3/4 (which I'm struggling to
> think
> > of!), but if we have either keyword it should mean 4/4.
> >
> > Overall that might make the main case more verbose, but I'd prefer that
> over
> > saying "strict is kinda strict, except it doesn't mean this last one,
> which
> > is size. That's something you need to specify separately, so it's only
> > sort-of strict."
> Which is an argument for moving the sizing stuff out to a separate
> property, actually.
> This has more reasoning behind it than just "naming things is hard".
> The "size containment" doesn't actually, when you think about it,
> *add* anything, containment-wise.  If you use it, you *must* provide
> means to size the element properly without reference to children
> anyway, and once you do that *you've achieved precisely the goal you
> sought in the first place* - the containment keyword doesn't optimize
> any further!  The only benefit is that it "keeps you honest" - if you
> *accidentally* make it depend on its children you'll very visibly
> break things (but you won't lose the perf benefits!).
> The main use of the size containment stuff is to (a) remind people
> that being able to size yourself without looking at children is a perf
> benefit, and (b) avoid loops in sizing behavior when you're doing some
> types of sizing stuff on your own, like in userland Element Queries.
> All the other containment benefits are things you can't achieve on
> your own and/or things that don't self-negate when you deal with the
> fallout of their effects.  (That is, whatever changes you have to make
> to accommodate their effects does not, by itself, achieve those
> effects, thus making the containment superfluous.)
> That said, I'm still not *opposed* to keeping sizing in the 'contain'
> property, as I outlined above.  I'm just also totally fine with it
> being split out into some sort of width-*/height-* property.
> ~TJ

Received on Friday, 18 March 2016 18:15:35 UTC