- From: Orion Adrian <orion.adrian@gmail.com>
- Date: Tue, 5 Jul 2005 13:10:27 -0400
- To: www-style@w3.org
On 7/5/05, Laurens Holst <lholst@students.cs.uu.nl> wrote:
> 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).
Perhaps a larger sampling of the data would be better. It looked like
assembler code to me.
> > 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 :).
Is it wrong for me to strive towards an ideal solution?
> > 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.
Again a misunderstanding of the data. A broader example would be useful.
> > 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.
Tables are lists at their core, but they add additional semantic
details which other simple lists do not.
> >>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.
I was talking about the general case.
> >>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.
It is not possible with rowspans without changing the underlying
structure. Colspans prevent column rearranging another very useful
tool.
Orion Adrian
Received on Tuesday, 5 July 2005 17:10:32 UTC