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

(as a general rule of thumb, when you read my mails about this, don't assume I expect to present a 'final' state of any kind, I really just want to start the debate and let people think about it, instead of just keeping the idea in relatively closed circles; input from the Sencha team and how they did use the <iframe> hack may be very valuable before taking actions or resolving issues, for example; at the end, the CSSWG will likely end up by making its own specification and will probably start from scratch so my goal is only to gather opinions and try to draw an high-level vision of what should be done; if parts of that work can be reused, that would already be a good achievement)


@TabAtkins:

> I also explained that my outline was for the lowest-level primitive
> only, and I planned to layer primitive layout managers on top of it
> which do simple things like lists and grids while maintaining the
> benefits.

Ok, take no offense but I genuinely thought when reading your mail you were saying you would reimplement the said layout managers in JavaScript from the basis of your restricted native viewport definition, which seemed like an overkill to me. If you just want to start by defining a canvas and "map" to it the other layout engines that can preserve the same benefits, that's fine.

Yet, I still believe there's no strong reason to restrict what you can do inside a viewport (the reason is simple: [1] even with a restricted viewport, you can create a wrapper that you position at top/left 0px and use any layout manager you want inside of this wrapper [2] I do believe that the creation of a parallel layout tree is already an improvement good enough to solve many issues faced today, even without any further restrictions/optimizations; making the layout parallelizable is already an achivement in a world where even smartphones are multicore).

I may be wrong, but I think that the good approach is "let web authors do their job the way they want and let's create optimized short paths for the useful cases like absolute-position, grids & flexbox (and let's advertise them, use them in tools, etc)", ie: letting the author choose the right level of optimization instead of letting him only the choice between two extremes. But, again, this is just a personal opinion.


@SylvainG:

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

Well, perf is one issue, and author usability is another one. I do not think that the tooling is sufficient now to envisage that the "fast layout engine" has to rely on javascript layouts only. This lack of tooling is very likely to change (for example, the work done by the Expression Blend team is awesome and very promising, and I expect Adobe to step up the game very soon, too) but the world wasn't made in one single day.

Received on Thursday, 20 December 2012 23:38:46 UTC