[whatwg] Exposing spelling/grammar suggestions in contentEditable

On 12/3/2010 2:05 AM, Adrian Sutton wrote:
> On 3 Dec 2010, at 00:16, Jonas Sicking wrote:
>> As a browser implementer, I can tell you I won't implement any
>> specification that isn't motivated by use cases. So I definitely think
>> you want to establish use cases if you're hoping to get browsers to
>> implement your suggestion.
>
> The major use case here remains being able to provide both spell 
> checking as you type and a customised context menu within rich text 
> editors.  Today that is not possible on any browser that I know of and 
> it's one of if not the biggest selling point for our non-JavaScript 
> editor (we offer both Java applet and Javascript based editors).  This 
> use case would require providing spelling suggestions, not just 
> identifying the location of spelling errors.
>
> Notably, users do not want the full browser context menu with some 
> custom additions (though obviously this would make a good option for 
> some users) - having "View Source" for example is quite damaging to 
> the usability of rich text editors since it would display a read-only 
> source without running the editors source filtering, as opposed to the 
> editor's built in source view which filters correctly and is editable. 
>  There are also styling considerations which are addressed quite well 
> with the current oncontextmenu handler and using pure HTML but which 
> would likely become quite difficult when trying to integrate with a 
> browser's native menu.
>
> What further information do you require around this use case?

Adrian:

Adding items to the context menu is not something that vendors are quite 
ready for, with their code bases. They're on their way: the resulting 
context menu would allow you to add items to the UAs menu. At some point 
an API may develop to style and/or script the context menu.  This is a 
limitation until context menus are more flexible.

I'd like to focus on exposing ranges, and I think that a more limited 
use case would benefit your users sooner.

Jonas:

I've outlined use cases, and I'm certainly willing to author the usual 
use "stories".

There is a lot of push back on this list regarding IME: I'd like to know 
the boundaries of acceptable use cases.
I'd like to have a technical discussion on the merits of the API, not a 
political/philosophical one on UA-Author control.

My current understanding is this:
Use cases which involve implementing IME with [canvas] are inappropriate 
at this time.
This is based on my understanding of comments by Oliver, Ian and Roc.

Use cases which can be solved by filing defects with the UA -may- not be 
appropriate.
This is based on my understanding of comments by Benjamin and Aryeh.

My counter-argument is well-defined by UAAG 2.0:
"2.1.5 Write Access: If the user can modify the state or value of a 
piece of content through the user interface (e.g., by checking a box or 
editing a text area), the same degree of write access is available 
programmatically. (Level A)".

With due respect for privacy and security:
"Some of the requirements of this document may have security 
implications, such as communication through APIs, and allowing 
programmatic read and write access to content and user interface 
control. This document assumes that features required by this document 
will be built on top of an underlying security architecture. 
Consequently, unless permitted explicitly in a success criterion, this 
document grants no conformance exemptions based on security issues."

All:

Use case: An online college course, using simple forum based software 
would like to include a spell checking button as part of a progressively 
enhanced contentEditable/textarea form area.
They would also like to allow users to set a preference to be warned if 
their post contains spelling mistakes before posting.

Reasoning: Get range would allow for counting if there are spelling 
mistakes.

Use case: A software suite for reviewing articles for publishing 
includes a step-by-step proofing mechanism for articles. One step 
involves checking for misspellings:
the application would display mis-spelled ranges within an active, 
styled node, where the user continues to focus, and continues to hit 
"next/ignore/add".

Reasoning: Copying the text content to a stylized area allows the user 
to maintain focus in an active area, instead of scrolling through a page 
themselves.
A similar mechanism might scroll the page for them, bringing the 
misspelled range into view. In the case of editing, it may be very 
inappropriate to "Add"
misspelled words to the system dictionary, but quite helpful to have 
them in a custom dictionary maintained by the application, in reference 
to the particular
article, author, subject or other item.

Those two use cases, I hope, fall within the guidelines as I currently 
understand them.


Here's the start of a more formal proposal:

getSpellingRanges
getSpellingRanges should accept an optional locale string, and some 
implementations MAY require such a locale string to be set.
This function returns a list of ranges from within the dom subtree.

Implementations MAY return an empty range list if security settings or 
other constraints require such behavior.
When an [input] tag is contained in the dom subtree, and contains a 
spelling error, the entire [input] element should be added to the range 
list.
The returned range list MUST NOT contain an [input type="password"] element.

NOTE: Implementers may limit the cases in which getSpellingRanges 
returns a populated range list.
  (e.g. return an empty list when more than 50% of the text input is 
identified as misspelled).

Received on Friday, 3 December 2010 12:41:59 UTC