- From: Simon Pieters <simonp@opera.com>
- Date: Mon, 25 May 2009 14:57:39 +0200
- To: public-html@w3.org
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. 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. It seems simpler to have spellchecking enabled or disabled on a per-editable region basis. 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>). -- Simon Pieters Opera Software
Received on Monday, 25 May 2009 12:58:30 UTC