[whatwg] Spellchecking proposal #2

[Lachlan Hunt]

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/