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 [1]). 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 author's suggestion?
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.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=339127#c7 -- Lachlan Hunt http://lachy.id.au/
