Re: [w3ctag/design-reviews] Display Locking (#306)

Hi,

Yes, there are some pretty big updates in the last few weeks!

In particular, based on feedback, we've significantly reworked the API shape. The new API takes into account the various pieces of feedback we've received from the community, some early-adopter experience, and drawbacks we discovered while implementing the previous API:
* The API is now declarative via a new `rendersubtree` HTML attribute to control rendering, and a `content-size` CSS property to express intrinsic sizing
* The declarative shape integrates much more easily with the way that rendering and the cascade generally work, allows adoption without any user script, and avoids significant complexity
* It also avoids a performance cliff / design flaw in the old API, where pages could get into a state where CSS containment isolation and locking state disagreed
* There are no "stale pixels" or "update in the background" methods in the current design iteration

I think the new API shape should admit an implementation of `rendersubtree` and `content-size` for existing browsers without a ton of effort, and already benefits use cases like (a) page loading performance, (b) infinite scrollers, and (c) makes it easier to add accessibility without sacrificing rendering speed, via the *activation* concept.

A "yielding" renderer, multi-threading or other advanced tech is not needed. I think this particular point addresses what may be the biggest concern raised in [this issue](https://github.com/mozilla/standards-positions/issues/135).

A new explainer is [here](https://github.com/WICG/display-locking). Thanks for taking another look.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/306#issuecomment-530171862