Re: Issues with spellchecking

On Tue, 28 Apr 2009, Simon Pieters wrote:
>
> The spellcheck attribute's missing value default is called the "inherit 
> state":
> 
>    The inherit state indicates that the element is to act the same way as
>    its parent.
>     -- http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#spelling-and-grammar-checking
> 
> But this does not match the spec's requirements: the inherit state 
> depends on the default behavior, and thus it would be clearer if it was 
> renamed to the "default state" and the paragraph above changed 
> accordingly.

Done.


On Mon, 25 May 2009, Simon Pieters wrote:
>
> The spec says
> 
> "User agents must only consider the following pieces of text as 
> checkable for the purposes of this feature: The value of input elements 
> to which the readonly attribute applies, but that are not immutable 
> (i.e. that do not have the readonly attribute specified and that are not 
> disabled)."
> 
> We never want to spellcheck password fields. Please call out password 
> fields here.

Done.


> The spec says
> 
> "For text that is part of a text node, the element with which the text 
> is associated is the element that is the immediate parent of the first 
> character of the word, sentence, or other piece of text."
> 
> "To determine if a word, sentence, or other piece of text in an 
> applicable element (as defined above) is to have spelling- and/or 
> grammar-checking enabled, the UA must use the following algorithm:"
> 
> This assumes that the user agent would want to have spellchecking 
> enabled on a per-word or per-sentence (or per-other piece of text) 
> basis, rather than per-editable region basis or per-document basis. If 
> spellchecking is enabled on a per-word or per-sentence basis, it is not 
> obvious how the user interface should work for enabling and disabling 
> spellchecking.
> 
> What's the use case for allowing spellcheck="true" or spellcheck="false" 
> in a subset of an editable region?
> 
> We could come up with a case where a mail app would say 
> spellcheck="false" on the quoted text, and spellcheck="true" on the text 
> that the user writes. But it's not obvious how it should behave when the 
> user splits the quoted text and writes some text in between. Also, it's 
> not obvious how it should behave when the user disables spellchecking 
> from the context menu and then enables it again, or how it should behave 
> when the user enables spellchecking for the spellcheck="false" part.

Make it so when the user overrides the choice, it overrides for the entire 
page (or section, or whatever level of atomicity the UI is able to convey).


> Opera and Firefox actually has spellchecking enabled or disabled on a 
> per-document basis for contenteditable. In Firefox, you have to specify 
> spellcheck="" on <body> or <html> for it to have an effect for 
> contenteditable regions.
> 
> Safari has a global preference for having spellchecking enabled or 
> disabled.
> 
> In conclusion, I think the spec should be simplified (until the state of 
> art in implementations is to have more fine-grained state of 
> spellchecking than per-document). Thus, to enable or disable 
> spellchecking for contenteditable, one has to specify spellcheck="" on 
> <html> or <body>, and other spellcheck="" attributes are ignored for 
> contenteditable. It's ok that <input> and <textarea> can inherit the 
> spellchecking state from parent, although one could argue that 
> spellcheck="" should only be allowed and have an effect on certain 
> elements (e.g. <body>, <input>, <textarea>).

A number of use cases have been put forward for the more fine-grained 
model (see roc's e-mail), so it seems worth at least supporting the more 
complex model for now. It doesn't seem necessary to expose this in the UI; 
the UI can just have page-wide overrides or editing-section-wide overrides 
without having to expose that each word can be individually controlled by 
the author.


On Tue, 26 May 2009, Simon Pieters wrote:
> 
> This could also be solved by having the spellchecker have knowledge 
> about the program syntax just like the spellchecker in Firefox has 
> knowledge to not spellcheck URLs.

It seems unlikely that Opera will implement support for, say, Sawzall, 
but one could easily imagine a Google-internal IDE Web app that had 
support for it and enabled and disabled spell-checking appropriately.


> At least in Opera we're not ready to move from per-document state of 
> spellchecking at this time, and with that in mind, the spellchecker spec 
> is unnecessarily complex.

This is equivalent to the user always having a page-wide override, which 
side-steps the majority of the algorithm in the spec. It does mean that 
some more advanced UIs won't work in Opera, though.

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

Received on Tuesday, 26 May 2009 09:55:32 UTC