[whatwg] Exposing spelling/grammar suggestions in contentEditable

[Jonas Sicking]

On Thu, Dec 2, 2010 at 4:07 PM, Charles Pritchard <chuck at jumis.com> wrote:
> On 12/2/2010 4:00 PM, Aryeh Gregor wrote:
>>
>> On Thu, Dec 2, 2010 at 3:30 PM, Charles Pritchard<chuck at jumis.com>  wrote:
>>>
>>> I can tell you, that blocking the issue does have real usability costs:
>>
>> I don't know if everyone here actually agrees with that.  Why can't
>> you rely on the browser's built-in spell-checking?  What are you
>> trying to do here?  What, in other words, is the actual use-case?  I
>> don't actually see you stating one in the thread (although maybe I'm
>> just missing it).  If there's no good use-case presented, then even
>> without security problems, no one is likely to spec or implement the
>> feature.
>
> 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.
>
> I'm resistant to heading into another use case debate here.

As a browser implementer, I can tell you I won't implement any
specification that isn't motivated by use cases. So I definitely think
you want to establish use cases if you're hoping to get browsers to
implement your suggestion.

> The red squigly [sic] lines current provided by proprietary IMEs do not
> cater many uses:
> They're meant to be generic, and they are.  High contrast, large font, and
> screen reading cases
> all come up here.
>
> If we can get standard behavior and naming out of it, and some implementers
> want to return
> an empty range list when it's called, that's fine with me.

If all you want is styling misspelled words, then all we need is to
add a pseudo-element selector which can be styled using CSS.

textarea::misspelled-word {
  background: pink;
}

/ Jonas