- From: J. Graham <jg307@hermes.cam.ac.uk>
- Date: Sat, 24 Jun 2006 14:39:41 +0100 (BST)
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.
Received on Saturday, 24 June 2006 06:39:41 UTC