Re: [css-display-viewport] Enabling fast layout for web apps via isolation

On Dec 20, 2012, at 7:35 AM, François REMY <francois.remy.dev@outlook.com> wrote:

> This week, I had some time to write about a proposal I discussed during TPAC with Tab Atkins called ‘display: viewport’ aiming at making CSS layouts more efficient by reducing the intrication level (aka: downplaying the impact of large and dynamic DOM trees on rendering performance), and I did so mainly because I talked about it at least two times on the mailing list during the past month without even making it official. Let's consider this as my Christmas gift to the WG ;-)
> 
> The use cases I’m trying to solve are multiple, but here are the most important ones:
> 
>   - Fast relayout experience when elements are added in the DOM on complex web pages (infinite scrolling, non-canvas html games, animated layouts...) [1]
> 
>   - Better layout isolation for web components (aka ‘sandboxing’), and a first step toward enabling new use cases like “local MQ” (element-size-based layouts) [2]
> 
> I won’t repeat in this mail everything I already said previously in the different specialized threads referenced at the bottom of this mail, but you can find a nicely written introduction (1.0) and prior art discussion (1.3) as well as some open issues in the ‘specification’ itself, which I invite you to have a look at.
> 
>       http://fremycompany.com/TR/2012/ED-css-viewport/

This draft has a number of inaccuracies which I'll comment on here without commenting on the higher level functionality:

> The third issue is that, when a wrapper or a web component is moved on a web page (expect via the ‘transform’ property which doesn’t affect the layout)

Transforms do affect layout, in that they affect overflow. Moving an element around inside an overflow:scroll element should update the scrollbars.

>  the layout/painting of the whole page needs to be recomputed, including the layout of the elements inside the moved element, while their layout should not depend on the position of the wrapper on the page.

Not necessarily. WebKit has a "layout positioned objects only" optimization that attempts to make moving out-of-flow positioned elements fast.

> Using an iframe solve both problems. Firstly, the layout inside the <iframe> is independent of the layout outside the iframe. When an iframe is moved, if its dimension doesn’t change, the layout of the document inside the iframe doesn’t have to be recomputed. Also, even when the dimension of the iframe changes, the layout of the document inside the iframe can be delayed and doesn’t impact the layout of the outer document. Last but not least, if the DOM tree inside the frame changes, it doesn't force a relayout of the outer document.

This is not true on many mobile platforms, which "flatten" iframes (expand the size of the iframe to reveal the entire inner document). iframe flattening is done so that users are spared from trying to scroll little areas on the page on a mobile device with a small screen.

Simon

Received on Thursday, 20 December 2012 19:46:30 UTC