- From: Thomas DeWeese <Thomas.DeWeese@Kodak.com>
- Date: Thu, 08 Jul 2004 08:17:12 -0400
- To: Robin Berjon <robin.berjon@expway.fr>
- Cc: www-svg@w3.org
Robin Berjon wrote: > Thomas DeWeese wrote: > >> If this information is properly exposed (as say a DOM >> method), then writing grid in script (or anything else) becomes >> pretty simple. However given the wide need for this feature >> I would find it as unfortunate that 1.2 doesn't include grid as >> that 1.1 didn't include flow text. > > Would you believe XHTML tables would be enough? Say that's what you had > how would you see the SVG working being inserted in there? Just dump it > in the <td>s? Well, I had proposed something slightly different (layout would be per CSS tables): http://lists.w3.org/Archives/Public/www-svg/2004Apr/0001.html (I seemed to have dropped gridRow in that suggestion which is obviously needed). <grid x/y/w/h> <gridRow rowSpan width/height> <gridCell colSpan width/height viewBox preserveAspectRatio> <gridText> <flowDiv/> (could have gridDiv - but doesn't really seem needed). </gridText> </gridCell> </gridRow> </grid> <gridRef xlink:href=""> Like 'flowRef' allows references to gridCell's 'out of line' so z-order can be easily manipulated. Using grid instead of 'table/td/tr' avoids people assuming all of xhtml is there (background, borders, etc). The gridCell needs to establish a viewport. You might consider allowing a 'naked' flowDiv to assume it flows into it's viewport (although you can get some nasty circular references for things like font-size="10%" :( ). > If you have specific use cases showing obvious limitations in the > current 1.2 stuff (as opposed to proposing a totally new feature) > they're welcome 1) Bullet lists. 2) UI layout 3) Tables (say like the 1.2 test results - have the wrong font and it goes wacko ;) > (especially welcome if they happen, say to pick a time > totally at random, before tomorrow's second half of the morning > Stockholm time). IMHO, with the addition of flowText it is _essential_ that we add min/maxWidth/Height to SVGLocatable (per my referenced note). I would almost certainly post a Last Call Comment on this. It is information the implementation must calculate for flowText, and it would be almost impossible (and very slow) for script to simulate them. As to you characterizing 'grid/table' as being a totally new feature I can find detailed proposals for grid dating back well over a year, and there have been mentions of automated layout that go back to the 1.1 timeframe. It may be totally new that the WG is paying attention but I think it is unfair to imply this is an attempt to add a new feature at the last moment. Also the last push for adding this was when the WG decided to add arbitrary SVG content to flowText. I was willing to draw the line at laying out text - but once you add flow layout of arbitrary graphics you should really add general layout of arbitrary graphics. >> Let's face it as soon as SVG did 'text' (as opposed to >> graphics that looked like text) - it needed flowText. I would >> strongly argue that as soon as it does flowText it needs grids. > > And once it does grids? :) Seriously, I think this completes a reasonable set of 'dynamic layout' tools. People will always come up with new features they want but I honestly think this provides a closure of functionality. With this addition text could reasonably interact with the rest of the graphics in SVG - currently this can only happen through lots of script - which almost no-one ever bothers to write as a result when the font changes a bit the whole document looks terrible.
Received on Thursday, 8 July 2004 08:19:20 UTC