Re: Stephen Ferg's Table Research

On Tue, Aug 14, 2007 at 07:42:05AM +0000, Ian Hickson wrote:
 
> 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 (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).

This is correct, as long as all other things are indeed equal.
> 
> 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.
> 
> An example of this would be the usemap="" attribute on <input> elements. I 
> recently decided to not supports this attribute on <input> elements in 
> HTML5, after having done a thorough study which discovered that in almost 
> all cases, pages that used the usemap="" attribute on <input> elements 
> actually behaved better in user agents that did not support that attribute 
> than in user agents that _did_ support it. [1]

First point, you aren't entitled to make any such decision about HTML 5. It is
this working group's role to make that decision, by consensus, if possible, or
by vote if not. It is your task to express the working group's decision in the
specification. Of course, if you want to argue for the deprecation of USEMAP
on INPUT, go ahead, but that will be an issue for the working group to
determine, taking your opinion into account along with that of every other
participant who chooses to express a point of view on the matter.

I also disagree with the claim that the abuse of a feature constitutes a good
reason for removing it. If the functionality it provides can be made available
in another way that is less likely to be subject to misuse, then that is
reasonable enough; but if the feature is necessary to provide important
functionality or semantics, then it should be included in the spec, and usage
guidelines, authoring tool guidelines and education can take care of showing
authors how to use it correctly.

All other things being equal, a feature that is judged easier to use correctly
is to be preferred. However, all other things are often not equal; and simply
removing functionality because some authors misuse it, or failing to provide
functionality on the ground that it is deemed liable to misuse, doesn't solve
whatever problem the feature was designed to address.

Openness to misuse is just a risk that has to be taken in providing a
semantically rich language, with some features that aren't visible (stricto
sensu) by default. The fact that certain markup isn't apparent in visual user
agents may make it possible for incorrect usage to slip through unnoticed, but
again, that is why we need authoring tools that assist in the authorial
process, and why knowledgeable HTML writers who understand the language
possess skills that can and should be brought to bear in Web content creation.

Received on Tuesday, 14 August 2007 08:34:53 UTC