[whatwg] Spellchecking mark III
mjs at apple.com
Wed Dec 31 07:15:27 PST 2008
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
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.
More information about the whatwg