W3C home > Mailing lists > Public > www-style@w3.org > March 2016

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 16 Mar 2016 17:16:11 -0700
Message-ID: <CAAWBYDBe5Qq7Xb3Cxi6ee4y4b6FxbwYM_mxinvhjpkdWKFAiqw@mail.gmail.com>
To: www-style list <www-style@w3.org>
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.


Received on Thursday, 17 March 2016 00:16:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:01 UTC