Intent to Ship: CSS Containment

[Emil A Eklund]

Contact emails
e...@chromium.org, le...@chromium.org, oj...@chromium.org

Spec
https://drafts.csswg.org/css-containment/

Summary
Containment provides a way to isolate a block from the rest of the page.
Layout containment provides a guarantee that an element's subtree will
not escape its bounds in a layout-impactful way.
Style containment provides a way to isolate certain CSS features, such
as counters, from the rest of the document.
Paint containment acts as a containing block for all objects,
including fixed. It also clips them. It's also a formatting context
and a stacking context.
These concepts may either be used separately or all together.

Link to “Intent to Implement” blink-dev discussion
https://groups.google.com/a/chromium.org/d/msg/blink-dev/9W80Kw-z3ss/7CLbeeqGBQAJ

Is this feature supported on all six Blink platforms (Windows, Mac,
Linux, Chrome OS, Android, and Android WebView)?
Yes

Interoperability and Compatibility Risk
Provides a new way to isolate a subtree from the rest of the document
which can result in different rendering in browsers that do not yet
support the feature. As for other implementations the interoperability
risks are quite low as reaching spec-compliance is quite simple.

OWP launch tracking bug
https://crbug.com/561713

Entry on the feature dashboard
https://www.chromestatus.com/features/6522186978295808

[PhistucK]

​Sorry for the intent-to-implement kind of notes, but here we go.​

On Mon, Apr 25, 2016 at 10:52 AM, 'Emil A Eklund' via blink-dev <blin...@chromium.org> wrote:

As for other implementations the interoperability
risks are quite low as reaching spec-compliance is quite simple.

​Since there are no public signals from any other browser (not even one), I would say that the interoperability and compatibility risks are pretty huge. Stuff may leak out to the page (obscuring other content, overlapping with other content, dimming a website completely unusable) in websites that only test in ​Chrome (not uncommon), potentially causing a massively bad appearance (sort of like Internet Explorer 6 versus Chrome in the early days of Chrome).

Also, no signals from web developers? So, what makes you think this is even needed (I agree it is, but still)?

☆PhistucK

[ben.m...@gmail.com]

For web developers, I'll signal interest from Facebook here. This spec seems useful in helping to give the site better control of perf on complex layouts, infinite scrolls, etc. I don't know that we could assess the actual impact without seeing this in practice.

A few thoughts:

1) Right now stylesheet recalc / layout and painting perf is hard to measure. I have a hard time envisioning how we'll get people to find good opportunities for these kinds of optimizations and measure their impact without a lot of guesswork.

2) Having a quick way to disable these optimizations via devtools will likely be useful for debugging.

3) How will this interact with scroll anchoring? Let's say I have this page:

<div class="feed">

  <div class="story" id="story1">...</div>

  <div class="story" id="story2">...</div>

  <div class="story" id="story3">...</div>

  <div class="story" id="story4">...</div>

  <div class="story" id="story5">...</div>

</div>

The "story" class has content containment (so *not* size).

The user loads the page. Stories 1 and 2 are above the fold so they get layout / painted. the user scrolls and now story 2 and 3 are in the viewport but story 1 is above the viewport.

A new story comes in. The site inserts a story above story1 but doesn't want to alter the view (as seen by the user). It'd be great if there were an interaction of scroll anchoring and containment so that the browser can realize that inserting a story above story1 will not change the current view the user is seeing and not have to do any layout. 

[Chris Harrelson]

Thanks for this feedback and engagement, it is really useful!

On Mon, Apr 25, 2016 at 11:01 AM <ben.m...@gmail.com> wrote:

For web developers, I'll signal interest from Facebook here. This spec seems useful in helping to give the site better control of perf on complex layouts, infinite scrolls, etc. I don't know that we could assess the actual impact without seeing this in practice.

A few thoughts:

1) Right now stylesheet recalc / layout and painting perf is hard to measure. I have a hard time envisioning how we'll get people to find good opportunities for these kinds of optimizations and measure their impact without a lot of guesswork.

2) Having a quick way to disable these optimizations via devtools will likely be useful for debugging.

3) How will this interact with scroll anchoring? Let's say I have this page:

<div class="feed">

  <div class="story" id="story1">...</div>

  <div class="story" id="story2">...</div>

  <div class="story" id="story3">...</div>

  <div class="story" id="story4">...</div>

  <div class="story" id="story5">...</div>

</div>

The "story" class has content containment (so *not* size).

The user loads the page. Stories 1 and 2 are above the fold so they get layout / painted. the user scrolls and now story 2 and 3 are in the viewport but story 1 is above the viewport.

A new story comes in. The site inserts a story above story1 but doesn't want to alter the view (as seen by the user). It'd be great if there were an interaction of scroll anchoring and containment so that the browser can realize that inserting a story above story1 will not change the current view the user is seeing and not have to do any layout. 

This is an example of a use case we hope to be able to optimize in the future on top of the containment features. Containment allows us to peformantly answer questions like "is this story offscreen," as you observed. That said, it's tricky work to get this right without bugs or unintended side-effects, which is why we are decoupling the feature of containment from specific promises about performance.

Right now we're working on the use case of throttling/avoiding layout etc for cross-domain iframes that are not visible. More tricky same-domain use cases will come later. And as you can imagine, with a declarative system like the web, it's hard to strike the right balance between flexibility for user agents to optimize, and guaranteed performance in specific scenarios.

 

On Monday, April 25, 2016 at 1:11:55 AM UTC-7, PhistucK wrote:

​Sorry for the intent-to-implement kind of notes, but here we go.​

On Mon, Apr 25, 2016 at 10:52 AM, 'Emil A Eklund' via blink-dev <blin...@chromium.org> wrote:

As for other implementations the interoperability
risks are quite low as reaching spec-compliance is quite simple.

​Since there are no public signals from any other browser (not even one), I would say that the interoperability and compatibility risks are pretty huge. Stuff may leak out to the page (obscuring other content, overlapping with other content, dimming a website completely unusable) in websites that only test in ​Chrome (not uncommon), potentially causing a massively bad appearance (sort of like Internet Explorer 6 versus Chrome in the early days of Chrome).

Also, no signals from web developers? So, what makes you think this is even needed (I agree it is, but still)?

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Ben Maurer]

On Mon, Apr 25, 2016 at 11:20 AM, Chris Harrelson <chri...@chromium.org> wrote:

This is an example of a use case we hope to be able to optimize in the future on top of the containment features. Containment allows us to peformantly answer questions like "is this story offscreen," as you observed. That said, it's tricky work to get this right without bugs or unintended side-effects, which is why we are decoupling the feature of containment from specific promises about performance.

Right now we're working on the use case of throttling/avoiding layout etc for cross-domain iframes that are not visible. More tricky same-domain use cases will come later. And as you can imagine, with a declarative system like the web, it's hard to strike the right balance between flexibility for user agents to optimize, and guaranteed performance in specific scenarios.

Totally understand where this is coming from -- you can't do everything immediately. I do worry this might lead to frustration with the feature. As a web developer, I might not understand that even though I used css containment that the browser just hasn't handled the optimization I'm thinking of yet. Then I give up on the optimization and don't revisit it 6 months from now when the browser does handle it. This is especially true given the lack of tools to debug if my use of containment is actually altering the layout performance (short of just refreshing a few times and making a guess if things are faster).

I don't think this should discourage you guys, but I think it is really important to make sure developers have the right expectations.

(i'm also a bit curious why we need the containment properties for iframes -- I'd think that iframes implicitly have strict containment and wouldn't need explicit specification) 

[Chris Harrelson]

Makes sense. I agree we should be careful to indicate the current performance expectations at first launch, to avoid false expectations.

 

(i'm also a bit curious why we need the containment properties for iframes -- I'd think that iframes implicitly have strict containment and wouldn't need explicit specification) 

We actually don't need them for iframes, since as you said iframes already have these properties implicitly. That work is going on in parallel with this feature. But since it's a related use case I thought it would be useful to mention it. :)

Chris

 

[Emil A Eklund]

> Since there are no public signals from any other browser (not even one), I
> would say that the interoperability and compatibility risks are pretty huge.

Mozilla has already implemented contain: paint [1] and are working on
contain: layout [2]. At least to me that sounds like a pretty strong
signal. I indicated this for the feature dashboard entry but failed to
mentioned it the intent to ship email. Thanks for bringing it up!

1: https://bugzilla.mozilla.org/show_bug.cgi?id=1178895
2: https://bugzilla.mozilla.org/show_bug.cgi?id=1178895

[Chris Harrelson]

LGTM1

[L. David Baron]

On Saturday 2016-04-30 09:59 +0900, 'Emil A Eklund' via blink-dev wrote:
> > Since there are no public signals from any other browser (not even one), I
> > would say that the interoperability and compatibility risks are pretty huge.
>
> Mozilla has already implemented contain: paint [1] and are working on
> contain: layout [2]. At least to me that sounds like a pretty strong
> signal. I indicated this for the feature dashboard entry but failed to
> mentioned it the intent to ship email. Thanks for bringing it up!

That said, we've implemented a bunch of the required restrictions,
but I'm still concerned that the spec isn't clear enough about what
the expected optimizations are. So it's not clear to me that the
feature is on track to ship (which it hasn't; it's still disabled
even on nightly).

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

[L. David Baron]

On Tuesday 2016-05-03 18:02 -0700, L. David Baron wrote:
> On Saturday 2016-04-30 09:59 +0900, 'Emil A Eklund' via blink-dev wrote:
> > > Since there are no public signals from any other browser (not even one), I
> > > would say that the interoperability and compatibility risks are pretty huge.
> >
> > Mozilla has already implemented contain: paint [1] and are working on
> > contain: layout [2]. At least to me that sounds like a pretty strong
> > signal. I indicated this for the feature dashboard entry but failed to
> > mentioned it the intent to ship email. Thanks for bringing it up!
>
> That said, we've implemented a bunch of the required restrictions,
> but I'm still concerned that the spec isn't clear enough about what
> the expected optimizations are. So it's not clear to me that the
> feature is on track to ship (which it hasn't; it's still disabled
> even on nightly).

Actually, ignore me. My spec feedback on this topic appears to have
been addressed.

[Emil A Eklund]

On Wed, May 4, 2016 at 3:07 AM, L. David Baron <dba...@dbaron.org> wrote:
> On Tuesday 2016-05-03 18:02 -0700, L. David Baron wrote:
>> On Saturday 2016-04-30 09:59 +0900, 'Emil A Eklund' via blink-dev wrote:
>> > > Since there are no public signals from any other browser (not even one), I
>> > > would say that the interoperability and compatibility risks are pretty huge.
>> >
>> > Mozilla has already implemented contain: paint [1] and are working on
>> > contain: layout [2]. At least to me that sounds like a pretty strong
>> > signal. I indicated this for the feature dashboard entry but failed to
>> > mentioned it the intent to ship email. Thanks for bringing it up!
>>
>> That said, we've implemented a bunch of the required restrictions,
>> but I'm still concerned that the spec isn't clear enough about what
>> the expected optimizations are. So it's not clear to me that the
>> feature is on track to ship (which it hasn't; it's still disabled
>> even on nightly).
>
> Actually, ignore me. My spec feedback on this topic appears to have
> been addressed.

Thanks for chiming in! Appreciate it.

[Rick Byers]

Excellent!  If Gecko is on track to ship without any known blocking design issues, then that indeed lowers the interop risk greatly.

Are there any signals from Edge and WebKit?  Surely Rossen (as both CSS WG chair and Edge layout dev lead) has some opinion on the matter worth mentioning, right?

[Ojan Vafai]

I don't think we have any written down thing we can point to here. My vague recollection is that Edge folks were generally supportive of this API, but my vague recollection is not really appropriate for an intent decision. :) 

[Dimitri Glazkov]

LGTM2.

[Rick Byers]

LGTM3

On Tue, May 10, 2016 at 12:49 PM, Dimitri Glazkov <dgla...@chromium.org> wrote:

LGTM2.