W3C home > Mailing lists > Public > www-style@w3.org > July 2005

Re: FAQ about reasons behind CSS

From: Laurens Holst <lholst@students.cs.uu.nl>
Date: Tue, 05 Jul 2005 16:00:51 +0200
Message-ID: <42CA9293.4010102@students.cs.uu.nl>
To: Orion Adrian <orion.adrian@gmail.com>
Cc: www-style@w3.org

Orion Adrian schreef:
> Beyond the gross misuse of table semantics, let's take a look at your
> data. Now remember nothing ever said you had to fill every cell with
> data. Secondly, what you're saying isn't a problem since there is no
> need for rowspan or colspan here. If what I'm understanding is
> correct, you're using a column with rowspans to specify labels into
> assembler code.

There’s not really a ‘direct’ mapping like that. It is a document which 
documents the function of addresses (with assigned labels).

> It breaks one of the fundamental promises of a table. That the rows
> and columns can be reorganized or sorted and it's going to be alright.

I’m not saying that HTML’s solution is ideal :).

> Code in it's linear nature would make no sense sorted. What you're
> looking for is <ol> to represent your code.

The data is in no particular order. It is also tabular data, not a 
simple list.

> In this case though you're using list (or more likely text) semantics
> in a table and complaining you're not getting the proper effect.

Of course I’m using list semantics. A list is a list of items. This is a 
list with different aspect of an item (e.g. address, label, 
description), in other words tabular data (‘arranged in rows and 
columns’ my dictionary says). Every table is a list. Just like ordered 
lists, unordered lists and definition lists are also lists.

>>Additionally: this also removes redundancy in the content (which is
>>something else than saving bytes). I would say that is desirable as well.
> It's not redundant though. The additional data is very important at a
> minimum because it can change. No one has yet dealt with the problem
> of what happens when a cell in the middle of a span changes. It's
> quite ugly.

It cannot change, this data is fixed and has been for about 20 years.

>>So, how the mechanism works precisely I do not care about, but there
>>must be a means to do this. Right now we have col- and rowspan, so col-
>>and rowspan I shall use. The semantics could be better, but it does the job.
> Unless you want to leave the door open for any data manipulation whatsoever.

Table sorting is possible with col- and rowspans... Although in the 
latter case it is slightly limited and the algorithm is not straightforward.


Ushiko-san! Kimi wa doushite, Ushiko-san nan da!!
Received on Tuesday, 5 July 2005 14:01:47 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:19 UTC