[whatwg] Spellchecking mark III

[Ian Hickson]

Apologies in advance if this covers old ground, it appears I missed some 
e-mails in the last round of e-mails about this topic.

On Tue, 30 Dec 2008, Anne van Kesteren wrote:
> 
> Opera wants to support this feature as well in due course, so I don't 
> think we would mind it being added to HTML5. Does it being in Chrome 
> mean it is also WebKit? If so, together with Firefox support, seems like 
> a compelling reason to add the feature.

On Tue, 30 Dec 2008, Maciej Stachowiak wrote:
> 
> The Google Chrome team has not submitted patches for such a feature to 
> WebKit. I am not sure if they plan to eventually submit it to mainline 
> WebKit. In fact, this is the first I've heard about Chrome having such 
> an extension.
> 
> It's not clear to me whether the feature is useful without seeing some 
> motivating examples. WebKit by default spellchecks (and grammar checks) 
> all editable parts of the document, and it is not obvious to me why one 
> would want to force it off for particular form controls or editable HTML 
> areas.

On Tue, 30 Dec 2008, Tab Atkins Jr. wrote:
> 
> Agreed.  This feature lives purely in user-space.  It can be convenient 
> for a user to be able to turn off spellchecking globally, or perhaps 
> even locally (FF exposes this currently through a right-click option on 
> editable areas), but I cannot see any reason for an author to have 
> control over this.  If I want to spellcheck an area, I want to 
> spellcheck it.  If I don't, I don't.

On Tue, 30 Dec 2008, Kornel LesiÅ~Dski wrote:
> 
> 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.

[snip more discussion back and forth about whether it's a good idea or 
not, or whether we could come up with some heuristics for it instead]

Based on the interest (not uniform interest, but interest nonetheless) on 
this topic, I've left the feature in the spec.

I don't think that heuristics would work -- in practice, little 
distinguishes the subject line from the To: line in GMail, for instance, 
but one wants spell checking and the other does not.


On Wed, 31 Dec 2008, Maciej Stachowiak wrote:
> 
> The proposal Hixie linked seems way overengineered for this purpose. 

Yeah, it's certainly not the simplest thing that could have been invented, 
I'll give you that.


> 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.

The user agent is allowed to override the author here, if desired.

The applicability to <input type=email> fields is mostly just a 
side-effect of the attribute applying to everything, which is because we 
want it to apply to contentEditable. The "true" state is so that subparts 
of contentEditable fields can have checking enabled when outer parts have 
it disabled.


> 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 contentEditable, it's easy to imagine that some parts shouldn't be 
spellchecked when others should, e.g. the editor might introduce a URL and 
not want that checked.


On Wed, 31 Dec 2008, Kornel LesiÅ~Dski wrote:
> 
> I don't like current proposal either, because "true"/"false" value is 
> inconsistent with other boolean attributes in HTML.

It's consistent with contentEditable, which it's intended to be used with.


> IMHO it should be nospellcheck="nospellcheck" (which also solves problem 
> of forcing spellchecking where it doesn't make sense).

That's a pretty ugly attribute name, though.


On Thu, 1 Jan 2009, Robert O'Callahan wrote:
> 
> A use case is editable program code, where spellchecking is disabled, 
> but where spellchecking is enabled inside comments. Maybe that sounds a 
> little far-fetched for today's Web applications, but some IDEs (e.g. 
> Eclipse) support this so it seems like something we'd want in the 
> future.

BeSpin, for instance, might want this, if they ever switch from <canvas> 
to contentEditable.


On Wed, 31 Dec 2008, Maciej Stachowiak wrote:
> 
> So I don't think this makes for a very compelling use case. It's like 
> arguing for a page layout feature based on something only WordPerfect 
> does.

I agree that it seems a bit overpowerful. Experience from Gecko suggests 
it's not all that bad though.


On Sat, 14 Feb 2009, Kristof Zelechovski wrote:
>
> The following sentences are *commands* that refer to browser actions:
> 
> 	Let automatic completion be turned _on_. (command)
> 	Let spell checking be turned _on_. (command)
> 
> The following sentences are *descriptions* that refer to user actions:
> 	Let this content _be_ editable. 
> (description what happens if the user wishes to edit this content)
> 	Let this element _be_ draggable. 
> (description what happens when the user attempts to drag)
> 
> Therefore I insist on having spellcheck="on".  Spellcheck="true" is 
> misleading because spellcheck is a command for the browser.

Consistency with contenteditable seems a worthy goal worth the price of 
this minor inconsistency, IMHO.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'