- From: Markus Ernst <derernst@gmx.ch>
- Date: Mon, 29 Nov 2010 09:25:42 +0100
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.
Received on Monday, 29 November 2010 00:25:42 UTC