[whatwg] Exposing spelling/grammar suggestions in contentEditable

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 
> ranges.

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:

   http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F


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 
> it's one of if not the biggest selling point for our non-JavaScript 
> editor (we offer both Java applet and Javascript based editors).

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 
> menu.

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.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 29 December 2010 17:47:51 UTC