W3C home > Mailing lists > Public > www-style@w3.org > December 2012

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

From: Sylvain Galineau <sylvaing@microsoft.com>
Date: Thu, 20 Dec 2012 21:16:58 +0000
To: François REMY <francois.remy.dev@outlook.com>, "Ian Hickson" <ian@hixie.ch>
CC: CSS WG <www-style@w3.org>, Tobie Langel <tobie@fb.com>, Tab Atkins Jr. <jackalmage@gmail.com>
Message-ID: <3C4041FF83E1E04A986B6DC50F0178291BEF89CE@TK5EX14MBXC222.redmond.corp.microsoft.com>
>I’m not saying JavaScript-based layout managers are bad (actually, I think they’re going to be more popular over time, 
>particularly when tools will support them better) but that most designers will probably want to use the layout managers 
>they know and love instead of relying on JavaScript code they can’t understand.

Not sure what you mean by 'good' or 'bad'. As in perf? 

As usual the answer is that it depends on your use-case. We've had some experience with the kind of model described by 
Tab for the type of control you describe in your doc e.g. a large grid of movie or book tiles, for instance, or any data
set for which user activity involves much panning while your app pools and recycles nodes etc. Pretty quickly 
you may find yourself spending a lot of time running your JS layout code. Even if that layout is simple it's 
not hard to reach a point where you spend more time running it than you've saved in engine layout time. (Some of 
which, to be fair, may also have to do with the aging clumsy string-based APIs we still use to do this kind of work today).

But as in everything there are trade-offs. It's quite possible that some scenarios would benefit from letting the app
do its thing in JS at runtime. But I suspect this will also take better, newer APIs and, as Tab pointed out, some additional 
primitives to optimize a few common building blocks.

Received on Thursday, 20 December 2012 21:18:35 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:22 UTC