[whatwg] Exposing spelling/grammar suggestions in contentEditable
Charles Pritchard
chuck at jumis.com
Fri Dec 3 12:41:59 PST 2010
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).
More information about the whatwg
mailing list