RE: Grid In 1.2?

With potential XForms and SVG integration, a layout mechanism would
enhance SVG as a hosting environment. I would also distinguish between
grid and table layouts. Grid layout is lightweight, and can be easily
implemented on Mobile platforms as well. Table layout is heavyweight and
it could be optional (falling back on the grid for mobile) and used for
increased sophistication.

In the context of recent W3C compound documents discussions, it seems
that some people would argue about overlaps with XHTML. However, if the
SVG spec. misses out on this critical feature, it would justify other
markups for creating web applications. Standard UI features will also
make easier adoption of SVG as a 'web-applications' runtime/hosting
environment.


Regards,
Shailesh

-----Original Message-----
From: www-svg-request@w3.org [mailto:www-svg-request@w3.org] On Behalf
Of Thomas DeWeese
Sent: Wednesday, July 07, 2004 8:38 PM
To: Gavin Kistner
Cc: Doug Schepers; www-svg@w3.org
Subject: 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.)
> 
> -- 
> (-, /\ \/ / /\/




**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

**********************************************************************

Received on Thursday, 8 July 2004 14:01:21 UTC