Re: [office] use cases for "is-subtable" attribute

[Thomas Zander <zander@kde.org>]

On Monday 09 July 2007 14:30:01 Oliver-Rainer Wittmann - Software 
Engineer - Sun Microsystems wrote:
> Dear TC members,
>
> from my point of view the main use case for the "is-subtable" attribute
> is the case, when a certain table cell inside a regular table is
> splitted.
>
> Think of a table consisting of two columns and 100 rows. If the user -
> for whatever purpose - splits a certain table cell of such a table
> vertically, it is in my eyes more sensible to reflect this split by a
> nested table with "is-subtable" attribute set. In my eyes the user
> doesn't intend to add another column to the table and set the col-span
> of 99 table cell from 1 to 2.

First of all; the user doesn't notice this col-span thing. But he *does* 
notice the sub-table being created as it behaves slightly different, 
especially with regards to cell borders and a11y.
In light of that concept I'm not sure I agree to your assertion. I think 
that if you ask 100 users that you show the resulting document if they 
like the effects of one better than the other, they will not care there 
are 99 rows with a cell that spans 2 columns.
Or, in other words, the internal data-representation of colspans are 
completely irrelevant to users as that is not going to be visible to them 
anyway.  As we can see from KWord1.x and html editing applications like 
Dreamweaver. Which do the colspan thing.

> As Andreas J. Guelzow in his mail - see
> http://www.oasis-open.org/archives/office/200706/msg00115.html -
> already pointed out, the tranformation from a table containing a nested
> table with "is-subtable" attribute set to a table build up using
> row-span and col-span can be very 'painful'.

Naturally, but this is a different thing. Convertion v.s. not creating 
this state in the first place.

Lets be clear;
a) The user action of splitting a cell *can* be completely implemented by 
the ODF-implementation to do col-span / row-span.  And the effect is a 
table that is better for accessibility and give better compatibility with 
other word processors.  The latter because things like borders are rather 
weird and cumbersome to apply and render when using a subtable. Html 
can't do it, for example. How about MSWord?

b) I heard there are valid use-cases for a sub-table (Sudoku!). It doesn't 
have to go away.

So, in the end, any application that aims to be interoperable and friendly 
for accessibility should do splitting of cells based on cell-spanning.
-- 
Thomas Zander

PGP signature