[whatwg] Exposing spelling/grammar suggestions in
chuck at jumis.com
Mon Nov 29 14:08:09 PST 2010
On 11/29/2010 1:53 PM, Ashley Sheridan wrote:
> On Mon, 2010-11-29 at 10:40 -0800, Charles Pritchard wrote:
>> > Date: Sun, 28 Nov 2010 15:54:04 +0100
>> > From: Christoph P?per<christoph.paeper at crissov.de <mailto:christoph.paeper at crissov.de>>
>> > To: whatwg group<whatwg at lists.whatwg.org <mailto:whatwg at lists.whatwg.org>>
>> > Subject: Re: [whatwg] Exposing spelling/grammar suggestions in
>> > contentEditable
>> > Message-ID:<62959690-0E26-4BBC-AB4F-F9726F24CAF9 at crissov.de <mailto:62959690-0E26-4BBC-AB4F-F9726F24CAF9 at crissov.de>>
>> > Content-Type: text/plain; charset=us-ascii
>> > Charles Pritchard:
>> >> > A method for a contentEditable section, along the lines of getSpellcheckRanges() would allow for content editors, to stylize and provide further UI controls around spell checking.
>> > Methinks this belongs into CSS:<http://lists.w3.org/Archives/Public/www-style/2010Oct/0849.html
>> Should the issue re-arise in the CSS groups: it seems that most of the
>> vendors are against exposing system dictionary identified misspelled words.
>> ::spelling would need to have the same level of security as a:visited --
>> only foreground, background color would accept alteration. Anything
>> else would expose the data being highlighted.
> Erm, how would that help? It's currently very easy right now to
> exploit the a:visited thing to grab an entire history list, which I
> presume is what you're on about?
Yes, that's what I'm getting on about. If spelling ranges are not
allowed, this would be a possible hole / limitation of CSS styling.
I do think it's reasonable to allow for a getSpellingRanges function.
I don't find Benjamin's objections to be sufficient to block, given the
existing scripting context:
1) "Detecting the user's language (including fine distinctions like
2) "Fingerprinting the user's system. Different systems likely use
different dictionaries with different coverage. You could use
dictionary profiles to guess at the user's system (potentially down to
operating system and version)."
Those are the two objections I heard to exposing spelling ranges inside
Both personal items are typically exposed in varying ways to the host
and scripting environment. It may make sense to require a language code,
to use the getSpellingRanges, if the item is important.
Complete anonymity, from fingerprinting profiling is really more the
realm of UA modes. Google Chrome has an incognito mode, for instance.
While I'm browsing incognito, it would not make sense for the spell
check to access words from a non-incognito context.
There were many other objections to exposing suggested spelling, and I
think that's a very separate issue now than exposing the misspelled ranges.
There are enough reasonable accessibility use cases to more strongly
consider exposing something like getSpellingRanges( preferredLanguage )
Browser vendors may consider limiting such lookups, and that receiving
more than a thousand lookups means that a script has gone awry. Doing so
would limit any reasonable chance of a brute force attack discovering
anything. A brute force attack with getSpellingRanges would use a
dictionary to fill a contenteditable area and test to see if the word is
in the system dictionary. The success of such an attack would be
reasonably limited were spelling lookups limited by the UA.
Can I get a maybe?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the whatwg