[whatwg] Exposing spelling/grammar suggestions in contentEditable
ian at hixie.ch
Wed Dec 29 17:47:51 PST 2010
On Sat, 27 Nov 2010, Charles Pritchard wrote:
> Is there room for discussion of an API to expose misspelled ranges of
> text in contentEditable?
What's the use case?
In practice, as far as I can tell, you'd either want the browser to handle
all the spelling and grammar checking itself, or you'd want to do it all
yourself. This would argue for an on/off switch for UA-provided checking,
which indeed is available (the spellcheck="" attribute), and for ARIA
exposure of the "spelling mistake" semantic, which is also available.
On Thu, 2 Dec 2010, Charles Pritchard wrote:
> The use case is highlighting a misspelled range, which is currently left
> up to the browser, as well as warning the user that there are misspelled
Doesn't letting the UA take care of this adequately address this use case?
If not, why not?
This may be an opportune time to remind everyone that there is a
process for adding new features, and it begins with establishing use
cases, researching existing solutions, and testing possible ideas:
On Fri, 3 Dec 2010, Adrian Sutton 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
Insofar as extending context menus is concerned, that's not a
spelling/grammar checking issue, it's a context menu issue -- and one that
is resolved by the contextmenu=""/<menu> feature in the spec.
> 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
I am skeptical about allowing Web pages decide what should be in the
context menu. Adding things is ok, but removing things leads to a broken
user experience. For example, as a user I frequently make use of "view
source", and I don't think it would be good for a page to be able to
remove that feature.
On Mon, 29 Nov 2010, Charles Pritchard wrote:
> Currently, there's no way for an author to markup spelling errors in
> text. A [spelling] tag would address that deficiency.
> This could be used for a number of reasons, from [sic]-style
> annotations, to conveying to the user that an area is misspelled using
> the same visual cues as contenteditable.
> At this point, it'd simply be a semantic element. If there's any
> traction, we could certainly talk about additional attributes or another
> name, such as sic: [sic]misspeld[/sic]
> Does the list need further use cases for its consideration?
_Any_ use cases would be a start. :-)
What's the problem you're trying to solve?
On Tue, 30 Nov 2010, Martin Janecke wrote:
> I support this idea and I'd certainly use it. For example, I'm currently
> copying an old rhyme book to hypertext and would love to mark
> historically correct (but now incorrect) spelling, spelling
> intentionally done wrong for better rhyming (yes, people did this in the
> past) and unintentional errors from the book semantically. I think it is
> important to note where those errors are done intentional (by me, the
> publisher of the web page) in contrast to errors accidentally added by
> me that differ from the copied book.
<mark> is the element for this purpose.
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg