Re: Proposal: :column pseudo-class

On 7/4/05, Laurens Holst <lholst@students.cs.uu.nl> wrote:
> Orion Adrian wrote:
> 
> >>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.
> >
> >
> Yes, but I don't think that matching values is desirable... The same
> value for a field does not imply that it is actually the same (and thus
> the table cells can be combined into one when adjecent), that is only
> the case when the field is a reference to something that is unique. E.g.
> this would not be the case for names. So there would need to be a
> semantic clue in HTML as to which rows are of type 'reference'.
>
> And even then, the table values do not necessarily need to be complete,
> e.g. it may reference to 'Bill Smith', and want to combine those rows,
> but there may be also another Bill Smith who has the same name but is a
> different person (e.g. determined by a different user ID or a different
> birthdate in another cell, etc).

In the case you just described yes, there would need to be a semantic
clue. Might I suggest an attribute value be added to td and th. The
purpose of which is to distinguish string-based representation from
value-based repesentation. This has the added benefit of being more
accessible anyways. It would also be easily implementable by machines
since most databases have this kind of information for exactly this
reason. String representation is abitrary and unreliable.

> So although my example using 'id' and 'ref' is verbose and not friendly
> to authors, it seems to me a better solution than the one which matches
> based on cell values, as you propose, because it can at least convey the
> *actual* relations and is machine-generatable and -parsable. With regard
> to forward references, that does not necessarily have to be a problem,
> as long as the ID is there eventually. The HTML label element does not
> have any problems with forward referencing an input field either.

Id and ref though requires forward looking, while possible, isn't
necessarily preferable (at a minimum from the human authoring angle).
Although it's better for machine processing than the currently
machine-ugly rowspan and colspan.
 
> >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.
> >
> I am not certain that would be in the domain of CSS... It is like, how
> the for= attribute behaves on label elements in HTML is also not part of
> CSS.

Well currently I believe that the for attribute is semantic with a
relationship that requires a presence in the source.

As for it belonging to CSS, the following three tables have the same
underlying semantics with different presentation. Changing between
them isn't possible with rowspan and colspan.

A B1 C1
A B2 C2
D E1 F1
D E2 F2

A B1 C1
   B2 C2
D E1 F1
   E2 F2

A
  B1 C1
  B2 C2
D
  E1 F1
  E2 F2

All of those above have the same semantics. So you could have a
property called row-grouping that would take the values none, inline,
outline. I'm playing around with the exact needs and syntax, but the
core idea behind it is there along with the benefits of such an
approach.

1) Easier semantic marking from a data source.
2) Allows row and column data manaipulation (sorting, column reordering).
3) Shows that values with identical string representations may have
different values. (because of the added value attribute).
4) Allows for alternate presentations more easily than with rowspan and colspan.
5) Others I haven't thought of.

Orion Adrian

Received on Monday, 4 July 2005 16:49:13 UTC