Intent to Ship: CSS content-visibility property

[Vladimir Levin]

Contact emails vmp...@chromium.org, rak...@chromium.org, chri...@chromium.org Explainer https://github.com/WICG/display-locking/blob/master/explainers/content-visibility.md Spec https://drafts.csswg.org/css-contain-2/#content-visibility TAG review https://github.com/w3ctag/design-reviews/issues/306 Summary Adds a CSS property called content-visibility, which allows automatic or script management of content visibility. When hidden, the element's contents (subtree or replaced element contents) are not drawn or hit-tested and have CSS containment applied, allowing for rendering optimizations. The 'auto' keyword allows for the user-agent to manage content visibility based on proximity to the viewport, whereas the 'hidden' keyword allows full script control of content visibility.

This intent-to-ship does not include the ‘hidden-matchable’ value or the ‘beforematch’ event, which are still being discussed. Link to “Intent to Prototype” blink-dev discussion https://groups.google.com/a/chromium.org/d/msg/blink-dev/Bh0bSdkQlbk/7n6b50N6AwAJ (note that the feature changed from being an attribute named rendersubtree) Risks

Interoperability and Compatibility This is a new feature, so the risk of interoperability problems is low. For the 'auto' keyword, since the content, when visible, appears rendered, a similar visual effect is achieved if the value is simply ignored (although it, of course, eliminates any performance benefits). The 'hidden' value can be approximated using visibility: hidden or display: none properties which make the content hidden, but do not have the same performance or accessibility characteristics (visibility: hidden still renders content and loses performance benefits, whereas display: none does not preserve render state and harms accessibility). Furthermore, the presence of this property can be feature-detected by the developer via @supports, so an alternative can be implemented if the browser does not support content-visibility. Firefox: Mixed public signals (https://github.com/mozilla/standards-positions/issues/135) The early position from Firefox considered previous iterations of this feature 'harmful'. We have worked extensively with Mozilla to address the feedback that caused this position, and believe we have addressed all of it. We have requested an updated position, but so far there has been no official update. Edge: No public signals Interest in the feature from in-person discussions. Safari: No public signals (https://lists.webkit.org/pipermail/webkit-dev/2020-May/031217.html) We have sent a request for position, but there have been no signals so far. Web developers: Positive We have been working with Facebook on the adoption of the 'auto' and 'hidden' values for content-visibility and the feedback from their prototype has been positive. Another site that participated in the origin trial found it an easy way to get a big performance win (performance trace before and after).

Ergonomics The ergonomics risk is low. This feature interacts nicely with contain-intrinsic-size, which provides a placeholder size when content is under size-containment (size containment is applied by the content-visibility in situations where content is not rendered). Activation The basic usage of content-visibility is easy to adopt by simply adding a few lines of CSS, in order to get progressive performance enhancement of an existing site. We had positive origin-trial feedback which indicated that the adoption of this feature in order to realize performance benefits was straight-forward. Security The security risk of this feature is low. One of the points raised by Mozilla is whether users of accessibility technologies can be detected using timing attacks with this feature. We believe that we addressed this concern in the spec draft by requiring that the performance characteristics of elements using content-visibility remain the same whether the user is relying on accessibility technologies or on visual output of the page. The implementation in Chromium meets this requirement.

Debuggability Elements hidden by content-visibility, when inspected, will cause DevTools to highlight the ancestor causing the element to be hidden, as well as text informing the developer/user that what is shown is the ancestor. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes Is this feature fully tested by web-platform-tests? Yes, currently implemented in third_party/blink/web_tests/wpt_internal/display-lock/css-content-visibility/. We will be migrating this to external/wpt as a part of the launch process. Tracking bug http://crbug.com/882663 Link to entry on the Chrome Platform Status https://chromestatus.com/feature/4613920211861504

[Manuel Rego Casasnovas]

Hi Vlad,

Great to see this moving forward and all the effort to move the spec
into the CSSWG.

On 02/06/2020 21:49, Vladimir Levin wrote:
> Summary
> Adds a CSS property called content-visibility, which allows automatic
> or script management of content visibility. When hidden, the element's
> contents (subtree or replaced element contents) are not drawn or
> hit-tested and have CSS containment applied, allowing for rendering
> optimizations. The 'auto' keyword allows for the user-agent to manage
> content visibility based on proximity to the viewport, whereas the
> 'hidden' keyword allows full script control of content visibility.

The "auto" and "hidden" values of "content-visibility" will enable style
containment. Style containment is still marked as "at risk" in the spec,
only Chromium has an implementation of that (which is kind of broken and
has been shipping on that state for a while already). I'm wondering if
the use of this new CSS property could make people end up enabling style
containment in more situations and depending on the "broken behavior".
Is there any plan to fix that at some point? Do you have any thoughts on
the topic?

By broken behavior of style containment I refer to the WPT tests
counter-scoping-*.html and quote-scoping-*.html that are failing in
Chromium (and the rest of browsers because Firefox doesn't implement
style containment, and WebKit doesn't support the contain property).

Bye,
Rego

[Vladimir Levin]

Hi Rego,

Style containment added by content-visibility is primarily caused by an edge case where counters inside a hidden element's subtree may affect counters outside of it. In order to implement optimizations that skip processing counters in the content of the element, we decided to put in style containment since that is exactly its intended use. In other words, style containment would prevent counters "leaking" outside of the contained element.

I believe also Firefox implements <li> under <ol> with counters, and we've had some discussion in https://github.com/whatwg/html/issues/4808 to see if that means that style containment should also reset the count of <li>s. We have plans in Chromium to implement <li>s with counters and in fact fix the counters as well (crbug.com/990657)

With regards to the current state of style containment, and whether it provides any optimization opportunities (https://github.com/w3c/csswg-drafts/issues/3280), I'm of the opinion that it provides enough value in content-visibility to warrant continued support (others may, of course, disagree). This means that yes, I believe we should fix Chromium's implementation (i.e. fix the bugs that you filed: crbug.com/882383 and crbug.com/882385, and the the one referenced above: crbug.com/990657). However, I don't think this should block shipping this feature, since style containment is already shipped.

Let me know if addresses your questions

Thanks,

Vlad

Bye,
  Rego

--
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/820d6bef-46b5-3a2e-94e2-eba6af97db98%40igalia.com.

[Manuel Rego Casasnovas]

On 04/06/2020 18:19, Vladimir Levin wrote:
> Style containment added by content-visibility is primarily caused by an
> edge case where counters inside a hidden element's subtree may affect
> counters outside of it. In order to implement optimizations that skip
> processing counters in the content of the element, we decided to put in
> style containment since that is exactly its intended use. In other
> words, style containment would prevent counters "leaking" outside of the
> contained element.
>
> I believe also Firefox implements <li> under <ol> with counters, and
> we've had some discussion
> in https://github.com/whatwg/html/issues/4808 to see if that means that
> style containment should also reset the count of <li>s. We have plans in
> Chromium to implement <li>s with counters and in fact fix the counters

> as well (crbug.com/990657 <http://crbug.com/990657>)

>
> With regards to the current state of style containment, and whether it
> provides any optimization opportunities
> (https://github.com/w3c/csswg-drafts/issues/3280), I'm of the opinion
> that it provides enough value in content-visibility to warrant continued
> support (others may, of course, disagree). This means that yes, I
> believe we should fix Chromium's implementation (i.e. fix the bugs that

> you filed: crbug.com/882383 <http://crbug.com/882383> and
> crbug.com/882385 <http://crbug.com/882385>, and the the one referenced
> above: crbug.com/990657 <http://crbug.com/990657>). However, I don't

> think this should block shipping this feature, since style containment
> is already shipped.

I didn't mean this should block anything, I was just wondering about
this relationship and the current plans regarding style containment.
Good to know you're planning to fix it.

Anyway I'd love to wait for the feedback from other vendors,
particularly Mozilla that has been providing valuable reviews on this
topic. I saw the changes on the spec to address their concerns, but it
would be nice to verify that they're happy with those changes.

> Let me know if addresses your questions

Yeah sure, thank you very much for your detailed reply.

Cheers,
Rego

[sligh...@chromium.org]

Thanks Vlad and Chris for all the background on this feature and how it has evolved.

A hearty LGTM1. Excited to see this land.

Regards

[Daniel Bratell]

LGTM2

/Daniel

--

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7a7f0318-8402-4465-a722-6d2363853675o%40chromium.org.

[Yoav Weiss]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3f5f9c77-7a97-d5c6-c545-5d19495158f8%40gmail.com.