Re: Dropping <input usemap="">

On Tue, Aug 14, 2007 at 10:19:56PM -0500, Robert Burns wrote:

> I agree with Jason 1005. I'd like to add that @usemap on INPUT is really 
> the same thing as @usemap on IMG. Its the same feature supported in a 
> polymorphic manner. Itt may  not have been implemented correctly in UAs, 
> however that can be dealt with by filing bug reports. The fact that it's 
> not correctly implemented in UAs may also pint to the reason and the 
> solution to why it has not been widely used by authors.

Or rather, this may explain why it has been used incorrectly by authors. Let's
review the strength of the case for omitting it: There is (apparently
unpublished) research purportedly showing that it is widely misused, and in
the researcher's opinion, its misuse (combined with UA implementation
inconsistencies) comprise good grounds for removing it.  However, as has been
pointed out in other discussions within the working group, this kind of
research is superficial in that it fails to explain why the feature is
misused. In general terms, there are numerous reasons why a feature may be
widely misused (or under-utilized), or why it may be implemented
inconsistently. Perhaps it is under-specified; perhaps there are historical
reasons (e.g., compatibility issues arising from early implementations that
haven't been made interoperable); perhaps the fiunctionality it provides isn't
judged to be sufficiently useful to be implemented; perhaps there are bugs in
implementations that haven't been fixed; perhaps authoring tools that support
it have associated bugs, poor user interfaces with respect to this feature,
etc.; perhaps the education of authors in its use has been inadequate - and
surely this is not an exhaustive list of possibilities.

As the foregoing list implies, the problem can be addressed in any of these
areas: UA implementations, authoring tools, usage guidelines and educational
materials. That a feature is not used, or misused, need not point to a design
flaw. On the other hand, knowing why a feature isn't applied correctly or
implemented consistently makes it possible to consider a range of solutions,
some of which would involve modifying the spec, perhaps redesigning the
feature, or indeed eliminating it altogether.

The central point here is that jumping straight from empirical findings about
misuse to normative proposals as to omission of the feature, is not only
rationally unsound but it also forecloses the other design choices available
to the working group, in the event that proper analysis exposes a problem that
warrants changes to the design of HTML.

Received on Wednesday, 15 August 2007 05:02:49 UTC