W3C home > Mailing lists > Public > www-svg@w3.org > July 2004

Re: Grid In 1.2?

From: Thomas DeWeese <Thomas.DeWeese@Kodak.com>
Date: Thu, 08 Jul 2004 08:17:12 -0400
Message-ID: <40ED3B48.3090604@Kodak.com>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:14:54 UTC