- From: Robert Burns <rob@robburns.com>
- Date: Tue, 7 Aug 2007 20:22:07 -0500
- To: Ben 'Cerbera' Millard <cerbera@projectcerbera.com>
- Cc: "Dan Connolly" <connolly@w3.org>, "HTMLWG" <public-html@w3.org>
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