Re: Grid In 1.2?

Hi Gavin,

    I think once you have the concept of 'flow' you are going to
need tables to keep everything playing nicely togeather.  For the
most part you could implement tables using elem.getBBox() but, as
with most things, it get's tricky with text because text's native
'bbox' is one really long line, so you need a second piece of
information which is sort of a minimum acceptable width, which
for (horizontal) text would be the width of the largest word.

    As for usecases, most UI's now days use some form of
'automated layout'.  Absolute positioning is not acceptable
unless you embed the font.  So any sort of reasonable 'UI' will
have to have implemented some form of layout in script - or
more likely they won't and the SVG will just look like crap to
the 20% of users that don't have exactly the same font the guy
used to layout the UI.

    I originally reproposed it because they had taken the step
of allowing arbitrary graphics in flow text.  If implementations
have to 'layout' graphics with text much of the needed infrastructure
must already be present so please expose it in a really useful way.

Gavin Kistner wrote:

> On Jul 5, 2004, at 2:19 AM, Doug Schepers wrote:
>> There has been much talk in the comunity about the need for some sort of
>> table or grid layout mechanism in SVG.
> I haven't been subscribed to or following the svg-dev mailing list; are 
> there a few glaring use cases crying out for it?
> I personally wouldn't mind seeing this, but I haven't (in my small 
> subset world) yet needed it.
> Is it primarily needed for aligning tabular data?
> For generating a layout which 'scales', by distributing element's 
> position as a percentage of viewport width/height?
> For layout out forms with labels?
> I think a few strong use cases would help determine the relative need of 
> this feature. (For example, looking at each use case we can see what the 
> pain level is for implementing a workaround, or if none exist.)
>> I've had conversations with several people about this issue, and we have
>> some fairly simple proposals for mechanisms. The most basic uses 
>> syntax much
>> like HTML tables, and even something like that, familiar to many authors,
>> would suffice for now. Other people suggested the Grid Bag Layout of 
>> Java.
> While I think the grid bag has nice functionality, I think that ease of 
> adoption would make something very much like HTML table layout the most 
> logical choice. (I'm probably one who suggested the grid bag at one 
> point, but in retrospect it took me a while to grok it.)
> -- 
> (-, /\ \/ / /\/

Received on Wednesday, 7 July 2004 20:39:04 UTC