Re: FAQ about reasons behind CSS

On 7/5/05, Laurens Holst <lholst@students.cs.uu.nl> wrote:
> 
> Mikko Rantalainen schreef:
> >> As an example, look at:
> >> http://map.tni.nl/resources/msxsystemvars.php#USRTAB
> >> Or the third table at:
> >> http://map.tni.nl/resources/msx_io_ports.php#switch_io
> >
> > I disagree. Both examples you provided would be perfectly understandable
> > if the rowspan were removed and missing cells were filled with the
> > repetation of cell data.
> 
> The meaning would be different (even though the point would probably get
> accross as well). None of these addresses is called USRTAB. The entire
> range #F39A-#F3AC is called USRTAB.
> 
> When looking at defining those labels, the following code is incorrect
> (and impossible):
> USRTAB: EQU #F39A
> USRTAB: EQU #F39B
> ...
> 
> (where EQU is the assembly equivalent of define). Nowhere in any
> specification does it say that address #F39B has the label 'USRTAB'.
> 
> So telling me to do it otherwise is like telling me to 'remove those
> <em> tags'. It changes the meaning of the content.

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.

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

> > I consider colspan and rowspan as premature optimization. If you're
> > afraid of extra bytes to transfer, just apply compression. Reduntant
> > strings can be easily compressed. OTOH, if you're afraid that author is
> > required to type more characters, then perhaps we should remove all
> > those long closing tags, too? Any closing tag could be easily replaced
> > with </> because it's clear in XHTML anyway which starting tag it should
> > be matched with...
> 
> I have no concern over bytes whatsoever, really :).
> 
> All I care about is the content. I want those cells to be combined into
> one cell. The end result (the adjecent cells being combined) is a
> typographical effect that conveys the semantics I desire to express, and
> I think rowspan is suitable to express such a them.

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.

> 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.

> 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.

Orion Adrian

Received on Tuesday, 5 July 2005 13:32:23 UTC