- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 2 Dec 2010 16:16:50 -0800
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
Received on Thursday, 2 December 2010 16:16:50 UTC