[whatwg] Spellchecking proposal #2

[David Hyatt]

If the user wants spell checking on in all textareas, then it should  
be on, regardless of what the page says.  I don't think the page  
should be allowed to override spell checking rules, since this is  
really a user decision.  For example, I know how to spell, so I don't  
want spell checking on in any controls.  A person with poor spelling,  
however, might want spell checking on in all controls.  I think it's  
totally inappropriate for a Web page to have any control over spell  
checking settings.

dave
(hyatt at apple.com)

On Jun 22, 2006, at 9:04 AM, Ian Hickson wrote:

>
> Based on the fedback recently received about how to do  
> spellchecking in
> HTML, here's a second proposal that uses an attribute to control it.
> Comments? (Don't worry about typos and other such minor mistakes.)
>
>
> AUTHOR REQUIREMENTS
>
> <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.
>
> In addition, there is a "spellcheck" DOM attribute on all elements. On
> HTMLInputElement and HTMLTextareaElement elements, it returns true if
> the content attribute is "on", false if the attribute is "off", and
> the user's preference if the attribute is not set. On other elements,
> it also returns the current state of spellchecking for that element,
> but this is not represented in a content attribute. The attribute may
> be set to "true" to enable spellchecking, or "false" to disable it. On
> elements other than HTMLInputElement and HTMLTextareaElement, this is
> only expected to be useful if contenteditable="" is used.
>
> Authors should set the document's language information, to enable user
> agents to accurately determine which dictionary to use when checking
> the spelling or grammar of user input.
>
>
> IMPLEMENTATION REQUIREMENTS
>
> All elements can have spellchecking enabled or disabled. UAs may allow
> the user to set this flag, and may have defaults that vary based and
> various heuristics or user preferences. Spellchecking can be enabled
> on an element while its children have it disabled. However, by
> default, user agents should enable spellchecking for an element if it
> is enabled for its parent element and not explicitly disabled for the
> child.
>
> If spellchecking is enabled on an element, the UA should indicate
> spelling and/or grammar errors in text nodes that are direct
> descendants of the element that the user is able to edit, in
> attributes of the element that the user is able to edit, and, for
> elements that are form controls that accept arbitrary text input, in
> the values of those elements.
>
> If spellchecking is disabled, the UA should not indicate spelling or
> grammar errors for that element's text and values.
>
> UAs should use the language of the element to determine what spelling
> and grammar rules to use. (Language information can come from the
> "lang" and "xml:lang" attributes, Content-Language HTTP headers, or
> other sources. q.v.)
>
> The HTMLElement interface has one new DOM attribute:
>
>   attribute boolean spellcheck;
>
> Every element remembers what its "spellcheck" DOM attribute was last
> set to, if it has ever been set.
>
> On getting, the "spellcheck" DOM attribute returns a value as
> determined by the following algorithm.
>
>  * If the element is an "input" element or a "textarea" element, and
>    the element has a "spellcheck" content attribute with the exact
>    literal value "on", then the DOM attribute must return true.
>
>  * Otherwise, if the element is an "input" element or a "textarea"
>    element, and the element has a "spellcheck" content attribute with
>    the exact literal value "off", then the DOM attribute must return
>    false.
>
>  * Otherwise, if the element is an "input" element or a "textarea"
>    element, then the DOM attribute must return true if spellchecking
>    is enabled on the element, and false otherwise.
>
>  * Otherwise, the element is neither an "input" element nor a
>    "textarea" element. If the DOM attribute has been set, then it must
>    return the value it was last set to.
>
>  * Otherwise, the element is neither an "input" element nor a
>    "textarea" element, and the DOM attribute has never been set. The
>    DOM attribute must return true if spellchecking is enabled on the
>    element, and false otherwise.
>
> Setting the DOM attribute has the effect determined by the following
> algorithm:
>
>  * If the element is an "input" element or a "textarea" element, then
>    the element's "spellcheck" content attribute must be set to the
>    literal value "on" if the attribute is being set to the "true"
>    value, and "off" otherwise. (This affects the spellchecking of the
>    element, see below.)
>
>  * Otherwise, the element's spellchecking should be enabled if the DOM
>    attribute is set to the value true, and should be disabled
>    otherwise.
>
> On "input" and "textarea" elements, setting the "spellcheck" attribute
> to the value "on" (whether dynamically or in the source markup) should
> enable spellchecking, and setting the "spellcheck" attribute to the
> value "off" should disable it. User agents must ignore all other
> values, such that setting the attribute to a value other than "on" or
> "off" does not change the spellchecking state for the element.
>
>
> -- 
> Ian Hickson               U+1047E                ) 
> \._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _ 
> \  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'-- 
> (,_..'`-.;.'