Re: Stephen Ferg's Table Research

On Aug 14, 2007, at 3:52 AM, Robert Burns wrote:
> On Aug 14, 2007, at 2:42 AM, Ian Hickson wrote:
>> (The following isn't intended to make any judgements on the various
>> proposals for how to handle associating header cells with data  
>> cells in
>> tables. I'm just discussing language design at an abstract level  
>> here.)
>>
>> There are two concerns with regard to specialised markup such as  
>> markup
>> intended for non-visual user agents. The first is that most  
>> authors won't
>> necessarily use the markup at all. That's not a huge problem,  
>> though of
>> course it is a disadvantage of such solutions and should be taken  
>> into
>> account
>
> Much of the discussion has moved away from requiring special things  
> for non-visual user agents. While AT may benefit more from these  
> solutions, most of these features we're discussing are proposed for  
> support in all browsing UAs. So while it is a specialized markup,  
> we're not talking about markup intended for only non-visual user  
> agents. In terms of specialized markup, the same thing could be  
> said of INPUT. Most authors won't necessarily use that element at  
> all. I can't draw any conclusions from that fact about whether  
> INPUT should be included in the language, and I don't think anyone  
> else could either. Regardless, like INPUT these features are in the  
> language for the authors that want to (sometimes need to) use them.
>
>> (in particular, all other things being equal, if two solutions
>> differ only in that one will get used by authors even when they don't
>> think of users with unusual setups but the other won't, then the  
>> former is
>> likely better).
>
> The former is likely better? How can you measure that. For example,  
> HTML 4.01 included three solutions to the problem (each with  
> slightly different solution niches: basic association, @scope  
> association and @headers association). For each of the niches these  
> solutions were designed for, one solution is better, in turn, than  
> the others (in many cases the others wouldn't even work). For  
> mildly complex tables, @headers is the best solution (the only  
> solution). For simple tables with corner header cells, @scope is  
> the better solution (though @headers would work). For the simplest  
> of tables where the corner header cells are left blank the basic  
> table algorithm is the best solution (though @scope and @headers  
> could be used instead).
>
>> The second is that authors will misuse the markup. This is a much,  
>> much
>> larger, and very real, problem. If markup is misused more than it  
>> is used
>> correctly, especially if the misuse is indistinguishable from  
>> correct use
>> from a computer's point of view, then the feature can in fact end up
>> making the user experience _worse_ for users in ususual  
>> configurations
>> than the absense of any feature at all.
>
> I would agree with that. However, the issue for us spec writers, is  
> what should be done about that? Should the features be dropped? Is  
> it a feature best handled by authoring tools (too complicated for  
> casual hand-coding)? Are there more clarifying prose we can provide  
> in the new recommendation? Dropping those features is only one of  
> many solutions. I look forward to when you get up to speed on the  
> wiki and you're ready to begin discussing solutions.

I meant to also say that another example where I think authoring  
tools are the answer is that of the new SECTIOn element. Here I think  
mistakes will be a likely result of adding this element: especially  
for authors hand editing source code. However, I'm quite excited bout  
it even with the likely errors. This is because for visual editing  
UAs  and content management systems it will be a very easy to use  
feature. That to me overrides the problems with hand editing such an  
element. I think the same thing applies to @headers, where good  
visual editing UAs can make the task of setting @headers a rather  
trivial task.

Take care,
Rob