>I think that the following is the simplest form possible:
>
><grid>
> <cell row='1' col='1' rowspan='2' colspan='2'>
> <use xlink:href='#background' x='0' y='0'/>
> </cell>
> <cell row='1' col='1'><rect.../></cell>
> <cell row='1' col='2'><rect.../></cell>
> <cell row='2' col='1'><rect.../></cell>
> <cell row='2' col='2'><rect.../></cell>
> <cell row='2' col='1' rowspan='2'><rect.../></cell>
></grid>
>
>What you think?
... that the examples I gave are much simpler, and more intuitive to use.
I think I'd prefer s.th. simple, like
<grid>
<row>
<cell><rect.../></cell>
<cell><rect.../></cell>
</row>
<row>
<cell><rect.../></cell>
<cell><rect.../></cell>
</row>
</grid>
<grid>
<col>
<cell><rect.../></cell>
<cell><rect.../></cell>
</col>
<col>
<cell><rect.../></cell>
<cell><rect.../></cell>
</col>
</grid>
As mentionned by Cameron:
== Start Quote ==
You don't seem to have addressed the issue I mentioned though.
And that is that because you are forced to list the elements
of the table from left to right then top to bottom,
that's the rendering order you will have to use.
Thus to control the order of which table cells get rendered,
there would have to be some rule other than
render-in-order-they-appear-in-the-document.
I think the problem with this method is that you are required
to mention the objects in the grid or table in a row-major,
column-minor order, which would force you to have
this rendering order. If you wanted, say,
a 3x3 arrangement of objects, layed out automatically
with this grid-mechanism, but you wanted another object
to appear over the centre object, but behind the outer objects,
you wouldn't be able to.
Similar situations where this happens already exist --
for example if you have a <g/> which you'll <use/> later on,
and you want an object to appear somewhere in the middle of it
(on the Z axis). In this case though you could decompose
the used <g/> and do it manually with the new object inserted
in the middle. But with the grid layout that won't work;
you can't decompose the grid because the grid needs to be
all together for it to determine the appropriate
{x,y,width,height}s for the grid elements.
== End Quote ==
The problem with <row><cell> and <col><cell>
is that you force an ordering drawing and you cannot do freaky stuff
like this:
<grid>
<cell row='1' col='1' rowspan='2' colspan='2'>
<use xlink:href='#background' x='0' y='0'/>
</cell>
<cell row='1' col='1'><rect.../></cell>
<cell row='1' col='2'><rect.../></cell>
<cell row='2' col='1'><rect.../></cell>
<cell row='2' col='2'><rect.../></cell>
<cell row='2' col='1' rowspan='2'><rect.../></cell>
</grid>
The following image grid driven is drawn: 2x3 grid
--- overlapping order --->
[zzzz] + [a][ ] + [ ][b] + [ ][ ] + [ ][ ] + [ ][ ]
[zzzz] [ ][ ] [ ][ ] [c][ ] [ ][d] |x|[ ]
[ ][ ] [ ][ ] [ ][ ] [ ][ ] [ ][ ] |x|[ ]
Resulting 2x3 grid:
[ z+a ][ z+b ]
[z+c+x][ z+d ]
[ x ][ ]
Having a span background, then rendering text,
then rendering text over, then rendering span stuff over
all this following a given grid.
While, I agree that <row><cell> is more HTML like <tr><td>
it as an inconvenient for dynamic overlapping SVG rendering.
Also, if we ever have 3D grid later on with 3D SVG,
you simply change cell to have:
<cell row='2' col='3' z-row='3'><rect/></cell>
__________
/__/__/__/x|
/__/__/__/|x|
/__/__/__/||/<< that one.
|__|__|___||/
|__|__|___|/
Sincerely yours,
Fred.
_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=features/featuredemail