OASIS Open Document Format for Office Applications (OpenDocument) TC

On Wednesday 27 June 2007 13:26:12 Lars Oppermann wrote:
> I think it would be possible to define a table style property in ODF,
> which specifies, that a surrounding cell border becomes the outer
> border for a nested table. I am unsure whether there is realy a
> requirement for such a feature as rowspan/colspan can be used to
> achieve the same visual result.

Hmm, not sure if this mixes very well with the "Collapsing border 
model" [1]

In this model the border should be 50% in the one cell and 50% in the 
other cell.  Which will get very complex and weird with the suggested 
model as the underlying model gets abused quite a lot if it has to do 
what the user expects.  That is; act like the B1 actually has a colspan 
of 2.

We should accept that when the user actually means to use colspan/rowspan 
from a user interface perspective we should make the tools to handle that 
more intelligent so its not too cumbersome compared to subtables.
Altering the fileformat to allow a workaround (the subtables structuring) 
to be saved seems wrong in my book.


1) 
http://testsuite.opendocumentfellowship.org/testcases/FormattingProperties/TableFormattingProperties/borderModelProperty/TestCase.html
-- 
Thomas Zander

On Wednesday 27 June 2007 15:57:02 Lars Oppermann wrote:
> Given that a requirement to make nested tables appear to be part of the
> surrounding table, it might be better to specify something along the
> lines of: If table:merge-with-surrounding is set to true, the cell
> contents (including any borders) of the enclosing cell are entirely
> replaced by the nested table (including any borders). See the attached
> image for an example.

But only when it would be legal to write the result as single table with a 
colspan/rowspan based solution.
Otherwise you still have the same problem of needless complexity in 
data-structures and rendering just for the gain of less user-interface 
code.

> Anyway - I don't think we need this until someone proves otherwise (by
> providing a relevant use-case).

I doubt there is one, so I agree with your assessment.

-- 
Thomas Zander

On Wednesday 27 June 2007 16:48:37 Andreas J Guelzow wrote:
> See above example. Failure to provide such support would complicate the
> description of that table.

To be sure we are talking about the same thing; the example you gave is 
naturally still possible using subtables.  I have not seen any suggestion 
to remove that feature.
The complexity of the example table is also such that its reasonable to 
expect the user to grasp the concept of subtables, since he would not 
have created the table otherwise.   Using join and split cells you can 
also reach a similar idea, but it would not act the same, so it would be 
an active user-intended idea to place the subtable where it is.

-- 
Thomas Zander

On Wed, 2007-27-06 at 17:13 +0200, Thomas Zander wrote:
> On Wednesday 27 June 2007 16:48:37 Andreas J Guelzow wrote:
> > See above example. Failure to provide such support would complicate the
> > description of that table.
> 
> To be sure we are talking about the same thing; the example you gave is 
> naturally still possible using subtables.  I have not seen any suggestion 
> to remove that feature.

I understand the initial request of the accessibility sc to suggest
exactly that. At least the argument made are applicable to any kind of
subtable.

Andreas
  

-- 
Andreas J. Guelzow, Professor
Dept. of Mathematical & Computing Sciences
Concordia University College of Alberta

The request from the accessibility SC is based on the finding, that 
nested tables are hard to use with A11Y tools. Such tools only provide a 
limited navigational context.

The specification allows for both, nested tables and row/colspans. In 
the case of a nested table, the specification also provides the 
is-subtable attribute, which merges the nested table with the 
surrounding cell.

This means, that implementors of editors currently have a choice of what 
kind of structure they generate when implementing a function like "split 
this cell" or "merge these two cells".

I think the request of the A11Y SC is mainly about providing guidance to 
implementors to prefer the use of col/rowspan for such functions. If 
subtables are preferred, the resulting documents are harder to use in an 
A11Y context.

So what I would propose for the specification is to state in the 
description of is-subtable, that using nested table structures may be 
problematic for non-visual renditions of the documents. Henceforth, 
col/rowspan should be used whenever appropriate to make the resulting 
document more accessible.

Cheers,
Lars

Andreas J. Guelzow wrote:
> On Wed, 2007-27-06 at 17:13 +0200, Thomas Zander wrote:
>> On Wednesday 27 June 2007 16:48:37 Andreas J Guelzow wrote:
>>> See above example. Failure to provide such support would complicate the
>>> description of that table.
>> To be sure we are talking about the same thing; the example you gave is 
>> naturally still possible using subtables.  I have not seen any suggestion 
>> to remove that feature.
> 
> I understand the initial request of the accessibility sc to suggest
> exactly that. At least the argument made are applicable to any kind of
> subtable.
> 
> Andreas
>   
> 


-- 
Sun Microsystems                Lars Oppermann