RE: Grid In 1.2?

I think that Cameron's example is a bit too verbose for this use case (why
use the flowText here?), but the idea is sound. The ability to position
elements relative to one another (rather than the viewport) is the key drive
for a grid. There are other ways this might be accomplished, such as
Cameron's own constraints system, but a grid/table is a solution that people
are familiar with, and which is fairly easy to use and implement.

A grid can allow the author to very easily create a UI that makes best use
of the space it has available, and keeps the controls in a consistent order
with respect to one another.

A grid can be very good for accessibility... each cell can have its own
title and desc, letting screen readers know what the content of the cell is,
and when used for tabular data, such as a calendar or keypad or spreadsheet,
can let a sightless person navigate with relative ease.

Here are a few thoughts I've had on Grid (just to get them out of my head):

* It could have manually resizable columns/rows; these are going to resize
anyway, when their values are relative and the viewport resizes, so why not
let the author specify that they can be resized by the user?

* If a cell is removed or hidden ( a nice feature not available in HTML
tables), I think it would be good to have a rule as to how the space is
filled up; I would assume that the other cells would expand to take up the
room, but perhaps if they were hardcoded with pixel sizes, they would either
stay in the same position or shift to make the margins equal across the row.
A similar idea goes for inserting new cells.

* Orientation (what I call "gravity"): HTML assumes a "gravity" that pulls
everything to the top left corner, unless there's something in the way (an
image, some text, or a rule-created space like a margin). SVG doesn't have
any gravity, so to port tables over directly from HTML seems like a kluge, a
duplication of effort, and a lost opportunity to make something better or
more in line with SVG's "metaphor" <shudder />. 

Since SVG already has (or will have) a mechanism for packing
differently-sized boxes along a row (that is, words along a flowText line),
why not reuse that for a grid? Rather than have defined rows and implicit
columns (with the colspans and rowspans), you can simply have rows as
container elements for cells (which are themselves containers for other
elements), and pack them in according to the same rules as text alignment.
Cell alignment is one way to change the gravity, so the cells themselves
shift left or right as desired. 

... Hey, wait... except for the fact that there is an explicit row
(flowRegion) to which a cell (flowImage) is assigned... this looks just like
flowRoot! It's just a bit simpler to implement (no need for wrapping), and
simpler for authors to use. So what would be the problem in putting this in
the Spec? That being said, there is often a need to have an implicit
columnar relationship, which might be a parameter of grid: <grid
useColumns='true'>, such that it would line up cells on different rows in
order of their declaration. Seems like it would be simple enough. 

If a robust but simple sXBL example of <grid> being mapped to <flowRoot> is
possible, then I would be forgo the inclusion of grid in 1.2, but I would
like to know that it could be done.

</brainDump>

Regards-
-Doug

Cameron McCormack wrote:
| 
| 
| Doug Schepers:
| > There has been much talk in the comunity about the need for 
| some sort 
| > of table or grid layout mechanism in SVG. FlowText is great, and I 
| > think that allowing images in it will be a fascinating 
| feature, but I 
| > don't think that it alone will satisfy most authors' needs 
| for a relative layout system.
| 
| +1 grids
| 
| A simple example of where a grid would be useful is a simple 
| form layout with text labels and text entry boxes, like this:
|              _____________
|   E-mail:   |_____________|
|              _____________
|   Password: |_____________|
| 
| You want the text entry boxes (assume they are just rects for
| simplicity) to have the same x coordinates.  This x 
| coordinate should be just to the right of the widest text 
| label.  You also want each label to be centered vertically 
| with respect to its text field.
| 
| I can imagine grid cells working as flow regions.
| 
|   <grid vertical-align="middle">
|     <gridRow>
|       <gridCell>
|         <flowPara>E-mail:</flowPara>
|       </gridCell>
|       <gridCell>
|         <flowPara>
|           <flowImage>
|             <rect width="20em" height="1.5em"/>
|           </flowPara>
|         </flowLine>
|       </gridCell>
|     </gridRow>
|     <gridRow>
|       <gridCell>
|         <flowPara>E-mail:</flowPara>
|       </gridCell>
|       <gridCell>
|         <flowImage>
|           <rect width="20em" height="1.5em"/>
|         </flowPara>
|       </gridCell>
|     </gridRow>
|   </grid>
| 
| (Maybe some of those flow* elements are redundant; I haven't 
| looked at them closely enough to know which ones are required 
| and which ones can directly contain content.)
| 
| I don't see any real impediment to using an HTML-style 
| algorithm for cell width determination.
| 
| Cameron
| 
| --
| Cameron McCormack
| |  Web: http://mcc.id.au/
| |  ICQ: 26955922

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.713 / Virus Database: 469 - Release Date: 6/30/2004

Received on Thursday, 8 July 2004 05:49:40 UTC