- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 31 Dec 2008 07:15:27 -0800
On Dec 30, 2008, at 7:20 AM, Kornel Lesi?ski wrote: > > On 30.12.2008, at 13:45, Geoffrey Sneddon wrote: >>> >>> I have therefore not added this feature to HTML5 for the time >>> being. If >>> there is more interest in this feature, please speak up. >> >> This seems stupid. If I want to have spell-checking, let me. Don't >> force it off. I don't see any reason to have it forced off, ever. > > > It's useful for fields that contain non-textual content, e.g. > product ID, license plate "number", CAPTCHA answer, etc. > Browser would mark these as misspelt, which might be confusing or at > least distracting. It does make sense I guess, that certain fields should not be subject to automatic spellchecking. However, three counterpoints: 1) At least Safari's spellchecking won't mark a word misspelled until you hit a space; fields that contain data which would be flagged by the spellchecker but which are also likely to contain internal whitespace are rare. 2) The proposal Hixie linked seems way overengineered for this purpose. First, it allows spellchecking to be explicitly turned on, potentially overriding normal defaults, but that seems wrong; an <input type="email"> should never spellcheck regardless of the page author says. I can't see any valid use case for the author turning spellchecking on regardless of UA defaults or user preferences. Second, it allows spellchecking to be controlled at a finer granularity than editability, for which again I think there is no valid use case. Both of these aspects make the feature more complicated to implement and harder to understand, compared to just having a way to only disable spellchecking at the same granularity as editing. In general it would be helpful if some of the Google folks who requested this feature and some of the Chrome folks who (apperently) implemented it could explain the actual use cases they had in mind. Regards, Maciej
Received on Wednesday, 31 December 2008 07:15:27 UTC