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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Tab Atkins Jr.
Ojan recently brought up with me that, for the most part, the
containment effects are fairly mild.  It's usually totally fine to
apply contain:strict liberally across your page, except for one
problem - the sizing part of contain:layout totally messes things up.

Now, the size containment is still *useful* - it keeps you honest when
you are in a situation where you can do fixed sizing, preventing you
from accidentally styling something to have non-fixed size.  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).

Ojan suggested splitting it out, though, so we end up with *four*
containment types.  Then "strict" would only be equal to "layout style
paint", not "layout style paint size", and would usually be safe to
throw around your page.  This should be a nice usability win, making
it easy to apply perf enhancements via 'contain' without risking
blowing up your page.

In other words, we'd change it to:

contain: [ strict | [ layout || paint || style ] ] || [ size | inline-size ]

and "contain:strict" would be equivalent to "contain: layout paint
style".  To get the *full* effect (with the easily-destructive size
containment) you'd have to write "contain: strict size;" or similar.

Alternately, we could remove the sizing part entirely from 'contain',
and move it to another property entirely, perhaps in the Sizing spec.
This keeps "contain:strict" having the naive meaning of "all the
containment", and perhaps gives a more usable/logical interface for
the size stuff.

Thoughts?

~TJ

Reply | Threaded
Open this post in threaded view
|

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

Paul Lewis
I think it's good to keep it as a single property, I just wonder if the term "strict" implies that it should include "size" as well as the other three. Not that I can think of a better keyword, but it's not strict if the size is implicit. It feels like "all" might be a softer way to imply "layout", "paint", and "style", with perhaps "strict" meaning all four. Either way I can make it work, it just didn't feel like "strict" meant "strict" if it only meant 3/4.
Reply | Threaded
Open this post in threaded view
|

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

Tab Atkins Jr.
On Fri, Mar 18, 2016 at 6:39 AM, Paul Lewis <[hidden email]> wrote:
> I think it's good to keep it as a single property, I just wonder if the term
> "strict" implies that it should include "size" as well as the other three.
> Not that I can think of a better keyword, but it's not strict if the size is
> implicit. It feels like "all" might be a softer way to imply "layout",
> "paint", and "style", with perhaps "strict" meaning all four. Either way I
> can make it work, it just didn't feel like "strict" meant "strict" if it
> only meant 3/4.

Having "all" imply 3 of the 4, not all of them, seems immensely more
confusing to me. ^_^

~TJ

Reply | Threaded
Open this post in threaded view
|

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

Paul Lewis
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."

On Fri, Mar 18, 2016 at 5:40 PM Tab Atkins Jr. <[hidden email]> wrote:
On Fri, Mar 18, 2016 at 6:39 AM, Paul Lewis <[hidden email]> wrote:
> I think it's good to keep it as a single property, I just wonder if the term
> "strict" implies that it should include "size" as well as the other three.
> Not that I can think of a better keyword, but it's not strict if the size is
> implicit. It feels like "all" might be a softer way to imply "layout",
> "paint", and "style", with perhaps "strict" meaning all four. Either way I
> can make it work, it just didn't feel like "strict" meant "strict" if it
> only meant 3/4.

Having "all" imply 3 of the 4, not all of them, seems immensely more
confusing to me. ^_^

~TJ
Reply | Threaded
Open this post in threaded view
|

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

Ojan Vafai-2
FWIW, internally when we were discussing this we called it "strictish". It's kind of a ridiculous name, but at least it wouldn't suffer from the confusion here.

/me ducks

In all seriousness, the version of this that doesn't include size is the one I expect to be the 90% use case for contains, so that's the one that should sound most natural in an ideal world.

On Fri, Mar 18, 2016 at 10:51 AM Paul Lewis <[hidden email]> 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."

On Fri, Mar 18, 2016 at 5:40 PM Tab Atkins Jr. <[hidden email]> wrote:
On Fri, Mar 18, 2016 at 6:39 AM, Paul Lewis <[hidden email]> wrote:
> I think it's good to keep it as a single property, I just wonder if the term
> "strict" implies that it should include "size" as well as the other three.
> Not that I can think of a better keyword, but it's not strict if the size is
> implicit. It feels like "all" might be a softer way to imply "layout",
> "paint", and "style", with perhaps "strict" meaning all four. Either way I
> can make it work, it just didn't feel like "strict" meant "strict" if it
> only meant 3/4.

Having "all" imply 3 of the 4, not all of them, seems immensely more
confusing to me. ^_^

~TJ
Reply | Threaded
Open this post in threaded view
|

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

Paul Lewis

Yes, I intuitively agree that the 3/4 case will be the norm, and if we have to call it "strict-ish" or similar then that's... Okay (kinda). I'm just sticking to my remark that "strict" implies 4/4, which will be confusing to developers.


On Fri, 18 Mar 2016, 17:55 Ojan Vafai, <[hidden email]> wrote:
FWIW, internally when we were discussing this we called it "strictish". It's kind of a ridiculous name, but at least it wouldn't suffer from the confusion here.

/me ducks

In all seriousness, the version of this that doesn't include size is the one I expect to be the 90% use case for contains, so that's the one that should sound most natural in an ideal world.

On Fri, Mar 18, 2016 at 10:51 AM Paul Lewis <[hidden email]> 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."

On Fri, Mar 18, 2016 at 5:40 PM Tab Atkins Jr. <[hidden email]> wrote:
On Fri, Mar 18, 2016 at 6:39 AM, Paul Lewis <[hidden email]> wrote:
> I think it's good to keep it as a single property, I just wonder if the term
> "strict" implies that it should include "size" as well as the other three.
> Not that I can think of a better keyword, but it's not strict if the size is
> implicit. It feels like "all" might be a softer way to imply "layout",
> "paint", and "style", with perhaps "strict" meaning all four. Either way I
> can make it work, it just didn't feel like "strict" meant "strict" if it
> only meant 3/4.

Having "all" imply 3 of the 4, not all of them, seems immensely more
confusing to me. ^_^

~TJ
Reply | Threaded
Open this post in threaded view
|

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

Tab Atkins Jr.
In reply to this post by Paul Lewis
On Fri, Mar 18, 2016 at 10:46 AM, Paul Lewis <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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

Paul Lewis

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., <[hidden email]> wrote:
On Fri, Mar 18, 2016 at 10:46 AM, Paul Lewis <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Tab Atkins Jr.
On Fri, Mar 18, 2016 at 11:14 AM, Paul Lewis <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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

Paul Lewis

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., <[hidden email]> wrote:
On Fri, Mar 18, 2016 at 11:14 AM, Paul Lewis <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Ojan Vafai-2
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 <[hidden email]> 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., <[hidden email]> wrote:
On Fri, Mar 18, 2016 at 11:14 AM, Paul Lewis <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Florian Rivoal-4
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 <[hidden email]> 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 <[hidden email]> 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., <[hidden email]> wrote:
On Fri, Mar 18, 2016 at 11:14 AM, Paul Lewis <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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

Ojan Vafai-2


On Mon, Mar 21, 2016 at 2:29 AM Florian Rivoal <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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., <[hidden email]> wrote:
On Fri, Mar 18, 2016 at 11:14 AM, Paul Lewis <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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

Levi Weintraub
 

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


On Mon, Mar 21, 2016 at 2:29 AM Florian Rivoal <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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., <[hidden email]> wrote:
On Fri, Mar 18, 2016 at 11:14 AM, Paul Lewis <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

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

Ojan Vafai-2


On Tue, Mar 22, 2016 at 1:26 PM Levi Weintraub <[hidden email]> wrote:
On Mon, Mar 21, 2016 at 12:06 PM, Ojan Vafai <[hidden email]> wrote:


On Mon, Mar 21, 2016 at 2:29 AM Florian Rivoal <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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., <[hidden email]> wrote:
On Fri, Mar 18, 2016 at 11:14 AM, Paul Lewis <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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

Paul Lewis

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, <[hidden email]> wrote:
On Tue, Mar 22, 2016 at 1:26 PM Levi Weintraub <[hidden email]> wrote:
On Mon, Mar 21, 2016 at 12:06 PM, Ojan Vafai <[hidden email]> wrote:


On Mon, Mar 21, 2016 at 2:29 AM Florian Rivoal <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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., <[hidden email]> wrote:
On Fri, Mar 18, 2016 at 11:14 AM, Paul Lewis <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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

Tab Atkins Jr.
On Wed, Mar 23, 2016 at 12:34 AM, Paul Lewis <[hidden email]> wrote:
> Agree! I like "content" and "strict" for "layout paint style" and "layout
> paint style size" respectively.

Yup, works for me.

~TJ

Reply | Threaded
Open this post in threaded view
|

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

L. David Baron
On Wednesday 2016-03-23 14:01 -0700, Tab Atkins Jr. wrote:
> On Wed, Mar 23, 2016 at 12:34 AM, Paul Lewis <[hidden email]> wrote:
> > Agree! I like "content" and "strict" for "layout paint style" and "layout
> > paint style size" respectively.
>
> Yup, works for me.

I'm a little hesitant about "content" since we talk about the DOM as
"content", i.e., a different part of the rendering pipeline,
separate from "style" and "layout" and "paint".

I also thought the earlier suggestion of not having an explicit
"size" part, but simply making it be triggered by fixed
width/height, may well be reasonable.  It would need to be
documented carefully, though.

-David

--
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                          https://www.mozilla.org/   𝄂
             Before I built a wall I'd ask to know
             What I was walling in or walling out,
             And to whom I was like to give offense.
               - Robert Frost, Mending Wall (1914)

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Ojan Vafai-2
On Sat, Apr 2, 2016 at 4:52 PM L. David Baron <[hidden email]> wrote:
On Wednesday 2016-03-23 14:01 -0700, Tab Atkins Jr. wrote:
> On Wed, Mar 23, 2016 at 12:34 AM, Paul Lewis <[hidden email]> wrote:
> > Agree! I like "content" and "strict" for "layout paint style" and "layout
> > paint style size" respectively.
>
> Yup, works for me.

I'm a little hesitant about "content" since we talk about the DOM as
"content", i.e., a different part of the rendering pipeline,
separate from "style" and "layout" and "paint".

Coming up with a name was really hard here...since you're only a little hesitant, will you be upset if we move forward with it anyways? I would say we should try to come up with a better name, but after many rounds of trying, I'm skeptical we'll succeed.
 
I also thought the earlier suggestion of not having an explicit
"size" part, but simply making it be triggered by fixed
width/height, may well be reasonable.  It would need to be
documented carefully, though.

There are some folks on our team that feel strongly there should be an explicit way to get the fully strict behavior so that authors need to rely on documentation, which I'm sympathetic to.
 

-David

--
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                          https://www.mozilla.org/   𝄂
             Before I built a wall I'd ask to know
             What I was walling in or walling out,
             And to whom I was like to give offense.
               - Robert Frost, Mending Wall (1914)
Reply | Threaded
Open this post in threaded view
|

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

Tab Atkins Jr.
On Sat, Apr 2, 2016 at 7:33 PM, Ojan Vafai <[hidden email]> wrote:

> On Sat, Apr 2, 2016 at 4:52 PM L. David Baron <[hidden email]> wrote:
>>
>> On Wednesday 2016-03-23 14:01 -0700, Tab Atkins Jr. wrote:
>> > On Wed, Mar 23, 2016 at 12:34 AM, Paul Lewis <[hidden email]> wrote:
>> > > Agree! I like "content" and "strict" for "layout paint style" and
>> > > "layout
>> > > paint style size" respectively.
>> >
>> > Yup, works for me.
>>
>> I'm a little hesitant about "content" since we talk about the DOM as
>> "content", i.e., a different part of the rendering pipeline,
>> separate from "style" and "layout" and "paint".
>
> Coming up with a name was really hard here...since you're only a little
> hesitant, will you be upset if we move forward with it anyways? I would say
> we should try to come up with a better name, but after many rounds of
> trying, I'm skeptical we'll succeed.
>
>> I also thought the earlier suggestion of not having an explicit
>> "size" part, but simply making it be triggered by fixed
>> width/height, may well be reasonable.  It would need to be
>> documented carefully, though.
>
> There are some folks on our team that feel strongly there should be an
> explicit way to get the fully strict behavior so that authors need to rely
> on documentation, which I'm sympathetic to.

Pending anyone coming up with a much better name in the near future,
I've editted the spec to split "layout" into "layout" and "size", and
added "contain" that does everything but "size" ("strict" still does
everything, so its behavior is unchanged).

~TJ