Re: FAQ about reasons behind CSS

Mikko Rantalainen wrote:

> Then I misundertood the data the table was trying to represent. I 
> still do not believe that it's sematically correct to even try to 
> present ranges of addresses and the addresses itself in a single 
> table. Instead, we *really* need a <grid> element to encode such data. 
> If you're trying to encode such data as a *strict* table, you can only 
> say that #F39A is *part of range* called 'USRTAB'.

Were I to come up with an XML structure for this data, I would probably 
write it down like this:

<label name="USRTAB">
   <base>F39A</base>
   <length>20</length>
   <label name="">
      <base>F39A</base>
      <length>2</length>
      <description>Address to call with Basic USR0</description>
   </label>
   ...
</label>

However, this is HTML, not XML with infinite expressiveness and zero 
semantics. There are many cases in HTML where the perfect solution can’t 
be expressed, but a suboptimal one can. It is a document format, not a 
database format.

> The fact that you need to combine multiple lines of data as one entity 
> (rows #F39A to #F3AC) suggests to me that the data you're trying to 
> represent isn't just rows and columns (that's what I'd consider as a 
> table). I think that in this case we have a table (Address, Length and 
> Description columns) and in addition we have an overlay that has been 
> put over the table to group some of the lines and those groups have 
> been given identifying names, such as "USRTAB". The colspan and 
> rowspan attributes transfer enough *presentation* so that this 
> overlaying can be done at least in visual user agent with some success

Any address has a function. Many addresses (ranges) have officially 
assigned labels (if they do not, the ‘name’ field is left empty). In the 
case of USRTAB, the base address is #F39A and it has a length of 20 
bytes. However, USRTAB can be divided into 10 sub-addresses, with 16 
bits for each ‘USR’ Basic function, which is the information this table 
carries. I could have only listed the base address and length, 
describing this subdivision in text, but when looking up an address to 
discover its function, this is more convenient.

I honestly think this is the best way to represent that :). I can’t see 
how I could reasonably do it differently. Except perhaps to add a 
secondary table inside the description field.

When sorting, because of the rowspan USRTAB can only be moved as a whole 
(the 10 rows at once) (and yes, sorting is possible), but that is no 
problem (probably even desirable?) because those addresses belong to 
eachother.

> (I wasn't the only one who misunderstood the table).

It is a fairly technical one :). Anyone who has knowledge about assembly 
programming, in particular in this context, will immediately understand 
it...

> Another correct way (IMHO) to repsent this data would be to use nested 
> tables (yes, I believe it transfers the data semantics better than 
> colspan and rowspan). In this case, you have first table
>
>     Table: MSX BIOS system area
>
>   System area partition name  |  Details
>   RDPRIM                      | <table>...</table>
>   WRPRIM                      | <table>...</table>
>   CLPRIM                      | <table>...</table>
>   USRTAB                      | **1**
>   ... ... ...

That would be bothersome. The nested tables for example don’t have 
headings for their columns (unless I plan to repeat that all the time, 
and hide it after the first instance), which harms accesibility. It is 
also difficult to style. The cure seems worse than the disease here.


~Grauw

-- 
Ushiko-san! Kimi wa doushite, Ushiko-san!!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Laurens Holst, student, university of Utrecht, the Netherlands.
Website: www.grauw.nl. Backbase employee; www.backbase.com.

Received on Wednesday, 6 July 2005 12:10:01 UTC