[whatwg] Exposing spelling/grammar suggestions in contentEditable

[Charles Pritchard]

On 12/3/2010 1:38 PM, Adrian Sutton wrote:
> On 3 Dec 2010, at 20:41, Charles Pritchard wrote:
>>> 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.
>
> Allow me to reiterate:
>>> Notably, users do not want the full browser context menu with some 
>>> custom additions ... - having "View Source" for example is quite 
>>> damaging to the usability of rich text editors ...
>
> It is possible today to replace the context menu with a custom one and 
> this works incredibly well for a usability perspective. I don't see a 
> need to change this.
>
> It is also possible today for rich text editors to have the built-in 
> browser spell checker mark any spelling errors. I don't see a need to 
> change this.
>
> What isn't possible is to have the combination of spell checking as 
> you type suggestions with a custom context menu. Inline spell checking 
> with right-click for suggestions has become almost the exclusive way 
> that authors use spell checkers. I regularly and repeatedly encounter 
> clients and prospective clients who are prepared to spend significant 
> amounts of money to solve this problem (by purchasing a non-JavaScript 
> based editor).
>

Yes, I understand that.

Your statement relates to a defect in the current flexibility of the 
"context menu".

I fully understand that, you wouldn't need the context menu to be more 
flexible, if you had access to suggestions, as you have your own custom 
context menu implemented.

Recognizing that "suggestions" can not be shared with the DOM, the 
alternative is to address defects in the context menu.

It seems to me that were the context menu more easily manipulated via 
scripting, your use requirement (having suggestions) would be handled 
without exposing the suggestions to the DOM.

Still, your use case does require that spelling ranges be made available.

-Charles