[whatwg] Spellchecking proposal #2
lachlan.hunt at lachy.id.au
Thu Jun 22 20:22:34 PDT 2006
Ian Hickson wrote:
> <textarea> and <input> elements may have a new attribute specified,
> "spellcheck". If specified, it must have either the value "on" or the
> value "off" (exactly, case-sensitive). The "on" value indicates that
> spellchecking is to be enabled, the "off" value indicates that
> spellchecking is to be disabled. If the attribute is omitted, the
> default value is to use the user preferences.
I don't particularly like giving the authors any control over spell
checking. For the majority of cases, I think browsers should become
smart enough to know whether or not to enable/disable spell checking
without any explicit author input, based on various heuristics (as I've
written about before ). In other words, for most cases, authors
should not need to use this attribute.
> UAs may allow the user to set this flag, and may have defaults that
> vary based and various heuristics or user preferences.
That's good, but it really should be a *should* or a *must*.
> Ok, so how can we ensure that spell checking is enable for GMail's To:
> line but enabled for its Subject line?
Ordinarily, <input type="email"> would handle no spell checking for
email addresses, but given that Gmail uses a textarea that contains both
people's names and email addresses, that may be one case where
heuristics may not give optimal results. If it were just e-mail
addresses, it wouldn't particularly matter because spell checkers can
already recognise e-mail addresses and not mark them as errors. But in
this case (and others like it), the user should be able to very easily
disable spell checking and have the browser remember that preference.
Do you think that that one small use case is strong enough to warrant
the use of a spellcheck attribute?
Roughly what percentage of all use cases would you expect heuristics and
user preferences to give suboptimal results, and thus require the
Is it really a major usability issue if a browser enables spell checking
for a field where the user wouldn't want it, considering it can be
easily disabled (or vice versa)?
For contenteditable use cases, roughly what percentage of them would
need the author to turn on or off spell checking? Given that the user
can add semantics to their content using elements, browsers should be
able to enable and disable spell checking for different sections. e.g.
if a user starts entering <code> into a contenteditable section, UAs
should be able to automatically disable spell checking for that content,
while still checking the surrounding text.
More information about the whatwg