[whatwg] Exposing spelling/grammar suggestions in contentEditable

[Markus Ernst]

Am 28.11.2010 17:27 schrieb Adrian Sutton:
> On 28 Nov 2010, at 15:52, Benjamin Hawkes-Lewis wrote:
>> On Sun, Nov 28, 2010 at 3:41 PM, Adrian Sutton
>> <adrian.sutton at ephox.com <mailto:adrian.sutton at ephox.com>> wrote:
>>> User's expect a rich text editor
>>> to override the browser default context menu to provide things like
>>> properties for images, lists, tables etc and the other stuff usually
>>> found
>>> in a rich text editor's context menu. However, once that is done, the
>>> browser's built-in spelling suggestions are no longer available,
>>> effectively
>>> losing support for inline spell checking.
>>
>> "The user agent may also provide access to its default context menu,
>> if any, with the context menu shown. For example, it could merge the
>> menu items from the two menus together, or provide the page's context
>> menu as a submenu of the default menu."
>>
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#context-menus
>
> It could, but it doesn't. Any browser that tried doing that would likely
> just run into compatibility complaints and have to revert it.
>
> More importantly, there's no way to instruct or even suggest that the
> browser should which leaves users without functioning spell checking and
> rich text authors with no way to meet the demands of users.

This looks like a context menu problem to me, not a spell-checking problem.

There are more occasions where an overridden context menu in 
script-driven parts of a webpage is annoying, e.g. it is impossible to 
use "print preview" or "back" on a google map. So, solving the 
context-menu issue might be a boost for a browser vendor.