Re: Intent to ship: CSS Containment

2019-05-27 Thread Daniel Holbert 
Followup: it turns out this wasn't quite ready to be enabled for 68, so I'm
now targeting Firefox 69 as the release where CSS Containment will be
default-enabled in release.

On Mon, Mar 18, 2019 at 12:01 PM Daniel Holbert 
wrote:

> As of today (March 18th 2019), I intend to turn CSS Containment
>  on by default on all platforms,
> in Firefox Nightly 68. It has been developed behind the
> 'layout.css.contain.enabled' preference.
>
> Other UAs shipping this or intending to ship it are:
> * Chrome & other Blink-based UAs (Chrome has supported since Chrome 52,
> released in 2016, according to caniuse
> ).
>
> Bug to turn on by default:
> * https://bugzilla.mozilla.org/show_bug.cgi?id=1532471 is where I'll be
> turning it on in Nightly by default (with a guard to only let it ship as
> far as early-beta)
> * https://bugzilla.mozilla.org/show_bug.cgi?id=1487493 is where I'll be
> removing the guard & letting it ride the trains to release, assuming
> everything goes well. (I anticipate that this will happen for the Firefox
> 68 release cycle.)
>
> This feature was previously discussed in this "intent to implement"
> thread:
> https://groups.google.com/d/msg/mozilla.dev.platform/q-uXVVClcU4/WswhXtlWqFIJ
> (though the spec and the feature have evolved a good deal since then)
>
> Note: we don't currently intend to ship support for one of the keywords
> mentioned in the spec & which Chrome sort-of supports -- "contain:style".
> Chrome doesn't implement this keyword properly/robustly, and we have doubts
> about whether the complexity & maintenance burden of a correct
> implementation would be justified by this keyword's limited use cases. See
> https://github.com/w3c/csswg-drafts/issues/3280 for more on this. The CSS
> Working group has marked this keyword as "at-risk", as a result of the
> discussion around these concerns.
>
> Many thanks to former-interns Morgan Reschenberg, Yusuf Sermet, and Kyle
> Zentner for their hard work on this feature!
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: CSS Containment

2019-03-19 Thread Daniel Holbert 
On Tue, Mar 19, 2019 at 2:13 AM Xidorn Quan  wrote:

> On Tue, Mar 19, 2019, at 6:01 AM, Daniel Holbert wrote:
> > As of today (March 18th 2019), I intend to turn CSS Containment
> >  on by default on all platforms,
> in
> > Firefox Nightly 68. It has been developed behind the
> > 'layout.css.contain.enabled' preference.
>
> IIRC this feature is designed to allow authors to provide hints to UAs for
> some optimization opportunities in the rendering pipeline.
>

Right, yeah - that's the primary intent.

Does our implementation also include any such optimizations for faster
> rendering, or is it currently just a basic implementation for conformance?
>

It does! The main one is
https://bugzilla.mozilla.org/show_bug.cgi?id=1497414 (making
`contain:layout size` elements reflow roots.

If we already include optimizations based on the hints, do we know how much
> they help the performance?
>

It entirely depends on the use-case, and of course it depends on web
authors opting in to use it.

The best results will come from adding containment around rapidly-changing
(i.e. frequently-reflowing) content, in a page with other
expensive-to-reflow content (which we can then ignore during the frequent
reflows, if we make the rapidly-changing area into a reflow root).  As one
example, we tried adding "contain:layout style" to the Web Console
text-entry area in https://bugzilla.mozilla.org/show_bug.cgi?id=1502524 ,
and this gave a ~50% reduction in time spent in reflow for a particular
stress test. However, we had to back it out in that case, because the Web
Console's functionality depends on some layout information *not* being
contained.  But that's an example of the sort of speedup that this can
give, in cases where it *is* appropriate to use.

- Xidorn
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: CSS Containment

2019-03-19 Thread Xidorn Quan 
On Tue, Mar 19, 2019, at 6:01 AM, Daniel Holbert wrote:
> As of today (March 18th 2019), I intend to turn CSS Containment
>  on by default on all platforms, in
> Firefox Nightly 68. It has been developed behind the
> 'layout.css.contain.enabled' preference.

IIRC this feature is designed to allow authors to provide hints to UAs for some 
optimization opportunities in the rendering pipeline.

Does our implementation also include any such optimizations for faster 
rendering, or is it currently just a basic implementation for conformance?

If we already include optimizations based on the hints, do we know how much 
they help the performance?

- Xidorn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: CSS Containment

2019-03-18 Thread Daniel Holbert 
On Mon, Mar 18, 2019 at 12:52 PM Daniel Holbert 
wrote:

> Summary:
>   CSS Containment gives web developers several ways of indicating that a
> subtree isn't influenced by the rest of the page. This may allow UAs to
> perform certain optimizations that they otherwise wouldn't be able to do.
>

Sorry, I slightly mis-stated that.  Closer to the truth:
"CSS Containment gives web developers several ways of indicating that a
subtree *does not influence the rest of the page*"

(The feature's design is mostly focused on preventing side effects from
*leaking out* of a subtree, rather than preventing outside things from
having side effects that leaking into a subtree.)


> Bug:
>   https://bugzilla.mozilla.org/show_bug.cgi?id=1150081
>
> Link to standard:
>   https://drafts.csswg.org/css-contain/
>
> Platform coverage:
>   All platforms
>
> Estimated or target release:
>   Firefox 68
>
> Preference behind which this will be implemented:
>   layout.css.contain.enabled (probably enabled by default in Nightly as of
> tomorrow, March 19)
>
> Is this feature enabled by default in sandboxed iframes? If not, is there
> a proposed sandbox flag to enable it? If allowed, does it preserve the
> current invariants in terms of what sandboxed iframes can do?
>   Enabled by default everyhwere. It has no impact on what sandboxed
> iframes can do -- it's purely a way of constraining sizing/painting
> behavior.
>
> DevTools bug:
>   None at the moment. This feature has subtle effects and I don't know of
> any useful devtools work to be done for it.
>
> Do other browser engines implement this?
>   Chrome (Blink) implements it as of version 52. Their
> intent-to-implement:
> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/9W80Kw-z3ss
>
> web-platform-tests:
>  https://wpt.fyi/results/css/css-contain
>
> https://wpt.fyi/results/css/vendor-imports/mozilla/mozilla-central-reftests/contain
>
> Is this feature restricted to secure contexts?
>  No, not currently. Note that Chrome doesn't restrict it, so it could
> conceivably create interop issues if we restricted it without getting them
> to also commit to restricting it.
>
> On Mon, Mar 18, 2019 at 12:39 PM Daniel Holbert 
> wrote:
>
>> Yeah, sorry - our earlier intent-to-implement thread predated our current
>> boilerplate (which includes stuff like test coverage).  And for
>> intent-to-ship, our boilerplate text is pretty minimal.
>>
>> Answering your direct question: yes, there is good web platform test
>> coverage for this feature.  I'll post a followup with answers to our other
>> typical intent-to-implement fields, too.
>>
>> On Mon, Mar 18, 2019 at 12:07 PM James Graham 
>> wrote:
>>
>>> On 18/03/2019 19:01, Daniel Holbert wrote:
>>> > As of today (March 18th 2019), I intend to turn CSS Containment
>>> >  on by default on all
>>> platforms, in
>>> > Firefox Nightly 68. It has been developed behind the
>>> > 'layout.css.contain.enabled' preference.
>>>
>>> Apologies if I've missed it, but I can't see any mention of whether this
>>> feature has — meaningful — cross browser (i.e. wpt) tests in the ItI
>>> thread or here.
>>> ___
>>> dev-platform mailing list
>>> dev-platform@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-platform
>>>
>>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: CSS Containment

2019-03-18 Thread Daniel Holbert 
Summary:
  CSS Containment gives web developers several ways of indicating that a
subtree isn't influenced by the rest of the page. This may allow UAs to
perform certain optimizations that they otherwise wouldn't be able to do.

Bug:
  https://bugzilla.mozilla.org/show_bug.cgi?id=1150081

Link to standard:
  https://drafts.csswg.org/css-contain/

Platform coverage:
  All platforms

Estimated or target release:
  Firefox 68

Preference behind which this will be implemented:
  layout.css.contain.enabled (probably enabled by default in Nightly as of
tomorrow, March 19)

Is this feature enabled by default in sandboxed iframes? If not, is there a
proposed sandbox flag to enable it? If allowed, does it preserve the
current invariants in terms of what sandboxed iframes can do?
  Enabled by default everyhwere. It has no impact on what sandboxed iframes
can do -- it's purely a way of constraining sizing/painting behavior.

DevTools bug:
  None at the moment. This feature has subtle effects and I don't know of
any useful devtools work to be done for it.

Do other browser engines implement this?
  Chrome (Blink) implements it as of version 52. Their intent-to-implement:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/9W80Kw-z3ss

web-platform-tests:
 https://wpt.fyi/results/css/css-contain

https://wpt.fyi/results/css/vendor-imports/mozilla/mozilla-central-reftests/contain

Is this feature restricted to secure contexts?
 No, not currently. Note that Chrome doesn't restrict it, so it could
conceivably create interop issues if we restricted it without getting them
to also commit to restricting it.

On Mon, Mar 18, 2019 at 12:39 PM Daniel Holbert 
wrote:

> Yeah, sorry - our earlier intent-to-implement thread predated our current
> boilerplate (which includes stuff like test coverage).  And for
> intent-to-ship, our boilerplate text is pretty minimal.
>
> Answering your direct question: yes, there is good web platform test
> coverage for this feature.  I'll post a followup with answers to our other
> typical intent-to-implement fields, too.
>
> On Mon, Mar 18, 2019 at 12:07 PM James Graham 
> wrote:
>
>> On 18/03/2019 19:01, Daniel Holbert wrote:
>> > As of today (March 18th 2019), I intend to turn CSS Containment
>> >  on by default on all
>> platforms, in
>> > Firefox Nightly 68. It has been developed behind the
>> > 'layout.css.contain.enabled' preference.
>>
>> Apologies if I've missed it, but I can't see any mention of whether this
>> feature has — meaningful — cross browser (i.e. wpt) tests in the ItI
>> thread or here.
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: CSS Containment

2019-03-18 Thread Daniel Holbert 
Yeah, sorry - our earlier intent-to-implement thread predated our current
boilerplate (which includes stuff like test coverage).  And for
intent-to-ship, our boilerplate text is pretty minimal.

Answering your direct question: yes, there is good web platform test
coverage for this feature.  I'll post a followup with answers to our other
typical intent-to-implement fields, too.

On Mon, Mar 18, 2019 at 12:07 PM James Graham 
wrote:

> On 18/03/2019 19:01, Daniel Holbert wrote:
> > As of today (March 18th 2019), I intend to turn CSS Containment
> >  on by default on all platforms,
> in
> > Firefox Nightly 68. It has been developed behind the
> > 'layout.css.contain.enabled' preference.
>
> Apologies if I've missed it, but I can't see any mention of whether this
> feature has — meaningful — cross browser (i.e. wpt) tests in the ItI
> thread or here.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: CSS Containment

2019-03-18 Thread James Graham 

On 18/03/2019 19:01, Daniel Holbert wrote:

As of today (March 18th 2019), I intend to turn CSS Containment
 on by default on all platforms, in
Firefox Nightly 68. It has been developed behind the
'layout.css.contain.enabled' preference.


Apologies if I've missed it, but I can't see any mention of whether this 
feature has — meaningful — cross browser (i.e. wpt) tests in the ItI 
thread or here.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: CSS Containment

2019-03-18 Thread Daniel Holbert 
As of today (March 18th 2019), I intend to turn CSS Containment
 on by default on all platforms, in
Firefox Nightly 68. It has been developed behind the
'layout.css.contain.enabled' preference.

Other UAs shipping this or intending to ship it are:
* Chrome & other Blink-based UAs (Chrome has supported since Chrome 52,
released in 2016, according to caniuse 
).

Bug to turn on by default:
* https://bugzilla.mozilla.org/show_bug.cgi?id=1532471 is where I'll be
turning it on in Nightly by default (with a guard to only let it ship as
far as early-beta)
* https://bugzilla.mozilla.org/show_bug.cgi?id=1487493 is where I'll be
removing the guard & letting it ride the trains to release, assuming
everything goes well. (I anticipate that this will happen for the Firefox
68 release cycle.)

This feature was previously discussed in this "intent to implement" thread:
https://groups.google.com/d/msg/mozilla.dev.platform/q-uXVVClcU4/WswhXtlWqFIJ
(though the spec and the feature have evolved a good deal since then)

Note: we don't currently intend to ship support for one of the keywords
mentioned in the spec & which Chrome sort-of supports -- "contain:style".
Chrome doesn't implement this keyword properly/robustly, and we have doubts
about whether the complexity & maintenance burden of a correct
implementation would be justified by this keyword's limited use cases. See
https://github.com/w3c/csswg-drafts/issues/3280 for more on this. The CSS
Working group has marked this keyword as "at-risk", as a result of the
discussion around these concerns.

Many thanks to former-interns Morgan Reschenberg, Yusuf Sermet, and Kyle
Zentner for their hard work on this feature!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform