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
