[whatwg] Spellchecking proposal #2

[J. Graham]

On Fri, 23 Jun 2006, L. David Baron wrote:

> In other words, authors will figure out what the heuristics are and then
> write markup to match the heuristics rather than to match the semantics
> of their content.  Authors will learn what triggers spellchecking (or
> not) in Mozilla, and write whatever markup, however inappropriate, gives
> the choice of spellchecking that they want.  Then other browsers will be
> forced to copy whatever Mozilla did.

Only if copying whatever Mozilla do provides a significant improvement in 
usability for the users of those other browsers. It may well be that, when 
it comes to spell checking, giving the author no control is better for the 
user than copying Mozilla.

The best reason I see to implement a specific attribute (or other 
mechanism) to control whether spellchecking is enabled or disabled on a 
particular control is to prevent abuses of e.g. the accept attribute so 
that authors use text/plain in order to enable spellchecking in Mozilla 
but, in doing so, break e.g. syntax highlighting in some future version of 
Konqurer which relies on a correct value for @accept. However I believe 
the implementation of any such attribute should be optional (as in "a UA 
MAY implement a spellckeck attribute to allow spellchecking to be enabled 
or disabled on an element"), but, if it is implemented, allowing the user 
to override the author should be a MUST or, if that is seen as being too 
dictatorial about UI, at least a SHOULD requirement.