Re: Proposal: :column pseudo-class

On 7/4/05, Laurens Holst <lholst@students.cs.uu.nl> wrote:
> Orion Adrian wrote:
> 
> ><tr><th>Location</th><th>Muscle Group</th><th>?</th><th>?</th>
> ><tr><td>Left Arm</td><td>Bicep</td><td>xxx</td><td>N</td></tr>
> ><tr><td>Left Arm</td><td>Tricep</td><td>yyy</td><td>N</td></tr>
> ><tr><td>Right Arm</td><td>Bicep</td><td>aaa</td><td>N</td></tr>
> ><tr><td>Right Arm</td><td>Tricep</td><td>bbb</td><td>N</td></tr>
> >
> Let's first establish that repetition is undesired, from an authoring
> point of view (both to save effort and for displaying purposes). This is
> something that colspan and rowspan are trying to resolve. Your example
> above nicely points out that there are two repetitions, in left/right
> arm, and in bicep/tricep, where only one could be caught using rowspan.

I will agree that repetition is undersired, but so is the alternative
to an even larger degree (my opinion based on observations). Colspan
and rowspan do a fine job of removing repetition at the cost of
removing dataview manipulation.

> Rowspan also has the disadvantage that it isn't really 'friendly'
> towards sorting... Although the sorting could consider rows which have
> rowspans as groups - something which would often be desirable anyway,
> but ah.

Colspan in the header is fine as long as you are ok with preventing
column re-ordering (another useful tool). Column re-ordering allows
you to bring your sort key out to the begining of the reading order
(left of LtR languages).

> The issue could be resolved differently using e.g. the following
> label/input-based syntax:
> 
> <tr><th>Location</th><th>Muscle Group</th><th>?</th></tr>
> <tr><td id="left">Left Arm</td><td id="bi">Bicep</td><td>xxx</td></tr>
> <tr><td ref="left" /><td id="tri">Tricep</td><td>yyy</td></tr>
> <tr><td id="right">Right Arm</td><td ref="bi" /><td>aaa</td></tr>
> <tr><td ref="right" /><td ref="tri" /><td>bbb</td></tr>

Not entirely though right? Since that would have the possibility of
putting the reference before the data if doing source manipulations.
It's also more verbose, doesn't easily allow the changing of data in a
cell and reduces readability at the source level. Plus what you wrote
below.

> Although that would be rather bothersome to author (you will have to
> create unique identifications for the table cells that get repeated), it
> would retain the actual 'coupling' of table cells, also when not
> adjacent and sorted.

The coupling is done by matching values, not explicit linking. Linking
simply puts more work on the author.

> In my opinion, it would give *more* semantic information, but that does
> not mean that colspan conveys no semantic information. It would also be
> better from a machine-processing point of view, but has a negative
> impact on authoring.

As far as I can predict, it would be worse than simply repetition for
machine processing. All presentation aid ins semantic information
processing. The underlying difference is that whether or not multiple
views could be created that show the same information without that
element. If there are, then the underlying element in question is
presentational.

>  From a more pragmatic point of view: HTML is what we have now. HTML is
> what we had. HTML is what people are used to. There likely already exist
> a ton of XML document languages which resolve the repetition 'problem'
> better than HTML does with col- and rowspan. Problem: those languages
> are not widely supported by user agents, nor are they widely used on the
> web.
> 
> So there you have it.

The beauty of what I'm talking about is that it requires no new HTML
contructs. Deprecation of colspan and rowspan is all that is
necessary. The work would then be moved off into CSS.

> Anyways, this has little to do with CSS anymore (pointing to www-style
> cc). Note by the way that I looked through the CSS 2.0 and 2.1 table
> modules chapters, and nowhere did I find colspan and rowspan
> properties... Maybe I didn't look well enough.

There isn't one. This is why it's still in the CSS list. I'm proposing
a series of properties that would cover the cases where a person would
want to merge cells.

Orion Adrian

Received on Monday, 4 July 2005 15:56:26 UTC