W3C home > Mailing lists > Public > www-style@w3.org > April 2015

[css-containment] Splitting up the value

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 24 Apr 2015 14:52:13 -0700
Message-ID: <CAAWBYDBHxsJ=tS4Q1DB4vDjtjQghTdiR_g-zbqSsbKB0e2aW-g@mail.gmail.com>
To: www-style list <www-style@w3.org>
One piece of feedback from the EWS earlier this week is that the
'contain' property might need to be split up into smaller pieces which
can be individually toggled, somewhat like the <iframe sandbox>

Currently, there are four distinct types of "containment" invoked by
the property:

1. Layout containment - the element stops paying attention to its
children for sizing purposes, defaulting to either 0x0 or 300x150 if
not otherwise specified. (I was surprised to find that this isn't
actually in the spec yet, but pretend it is.)
2. Paint containment - the element's contents are strongly clipped to
the element's boundaries.  This is #1, #4, and #5 in the list defining
strict containment
3. Scroll containment - the element doesn't scroll.  This is #2 and #3
in the list.
4. Style containment - none of the element's descendants have an
effect on how styles are computed for any other element in the
document.  This is #6 and #7 in the list.

During the talk, there was some discussion over whether scroll
containment was necessary; it seemed like it would sometimes be Too
Much Containment, and prevent people from being able to use the
property.  Discussion with Ojan just now pointed out the it's not even
necessary to add - paint containment + overflow:visible gives the
exact same behavior.  Since this is the default, we'll get scroll
containment for free on most elements anyway, and don't need this
property to address it.

Of the remaining three, layout containment and paint containment seem
like they can be usefully separated.  One can imagine common cases
whether you'd want one of them, but not the other.  For example, the
G+ stream can use paint containment on its posts, but needs layout to
work normally so that heights are auto-calculated.

It doesn't seem like style containment is particularly important to
separate out either way, but pulling it out gives us a simple naming
scheme, so I'm doing so.

This brings me to the following proposal for a new grammar:

contain: none | strict | [ layout || paint || style ]

Where layout/paint/style turn on the appropriate form of containment,
and "strict" turns on all three.

It feels like this a reasonably usable syntax for authors.  Thoughts?

Received on Friday, 24 April 2015 21:53:01 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:50 UTC