Re: complex tables: heading cells and summary cells

Hi Ben,

On Aug 7, 2007, at 8:09 PM, Ben 'Cerbera' Millard wrote:

> Contrived tables are risky. You can end up thinking mechanisms are  
> needed to address a hypothetical use-case, only to find such use- 
> cases don't actually exist.

Working with actual tables is risky too. It's possible that spec  
designers can end up presuming that the work of an author was what  
the author wanted to do rather than what the author would have done  
if a better language facility existed. My point in calling them  
complimentary is that we need to follow both approaches at the same  
time. Otherwise we'll face a blind spot by taking a myopic approach.

> Working with genuine examples found on the web gives an automatic  
> reality check. So your efforts get focussed on how to express cell  
> arrangements to users which real authors definitely build.
>
> As such, I agree with Ian Hickson's recent clarification [1] that  
> tables built solely to demonstrate theoretical association needs  
> ([2]?) are not genuine and should probably be ignored. It's great  
> to see people getting their hands dirty but let's work on real issues?

Ignoring an aspect of reality is never a good thing: certainly not  
for designers of a spec. It's important to use both tables that we  
can find in the wild and abstract mechanisms to understand how to  
change the spec. After all we cannot come up with a different spec  
for each author's table. That would never be interoperable. We have  
to eventually abstract from all of the real world tables to create an  
interoperable spec of eventually to create an implementation that  
implements an abstract algorithm that works with those concrete tables.

> I also advise against making the term "heading" and alias for the  
> term "header" and then deleting "header" from our vocabulary. These  
> terms already have clear and specific meanings when discussing  
> HTML. Diverging from these definitions causes inconsistency which  
> makes discussions harder to understand, imho. As well as making  
> them a little harder to track via e-mail subject lines. :-)

Again, this is in an area where these terms are not well-understood.  
The draft itself uses them in a confused way (as I've already  
mentioned). Here on tables we have two constructs a THEAD (a header  
in my terminology) and a TH (a heading in my terminology). I could  
just refer to them as THEAD and TH, but that further masks the  
confusion between them that I'm trying to unmask.

> When talking about HTML table headers, I think "headers" is the  
> best word available.

OK, then what about table data cell headings? What's the best word  
for that? Is that different than the headers/headings contained in a  
THEAD which is more like a THEADER (a table header). If you find  
yourself translating all of these different terms back into headers,  
then that's the very problem I'm trying to avoid. There are different  
concepts here that all have the same word. That's a recipe for disaster.

> Perhaps Dan Connolly has some thoughts about what research is  
> valuable and the consistent use of terms within this Group?

Perhaps. Sander has begun a wiki page [1] to help address the issue  
too. There's no way we can revise a recommendation as significant as  
HTML without a reexamination of our terms and definitions

Take care,
Rob.



[1]: <http://esw.w3.org/topic/HTML/CommonVocabularyAndDefinitions>

Received on Wednesday, 8 August 2007 01:22:17 UTC