- From: Orion Adrian <orion.adrian@gmail.com>
- Date: Thu, 30 Jun 2005 07:22:12 -0400
- To: www-style@w3.org
On 6/30/05, Laurens Holst <lholst@students.cs.uu.nl> wrote: > Orion Adrian schreef: > >>And I'm not really sure whether it is worthwhile to sacrifice proper > >>incremental rendering in favour of being able to specify such grids. > > > > This problem can be fixed without breaking incremental rendering in > > most cases, but it requires come changes in how we think about > > layouts. It also still has a lot of the problems (e.g. complex > > interactions) that need to be solved. > > What I mean is, the number of designs where using e.g. a grid layout > which breaks incremental rendering is limited (after all, look at all > the current CSS-based web pages, and those aren't even using > display:table and absolute positioning), and other methods should be > tried first :). Grid layouts, done right, don't have to break incremental rendering except in a very few number of layouts. The cost, which I consider to be a benefit is to take the layout job out of CSS and move it into another language. This langauge would specify layout and the layout would specify what kinds of content go in each area. Organize your HTML to be organized in the same order and imcremental rendering is saved. > <separator /> hehe > By the way, I wonder how the grid layout is insufficient. Your approach > seemed to be just reordering of the document structure (or I must look > better). The grid layout works based on a layout you want to achieve. It > is indeed a different perspective, but it can do the same, and I think > the grid one is more appropriate to CSS? <hblock> and <vblock> were designed to place elements horizontally or vertically. Tables could also be included. It wasn't simply reordering content. Orion Adrian
Received on Thursday, 30 June 2005 11:22:19 UTC