[whatwg] Exposing spelling/grammar suggestions in contentEditable
jonas at sicking.cc
Thu Dec 2 16:16:50 PST 2010
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
> 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.
More information about the whatwg