<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
    <title></title>
  </head>
  <body bgcolor="#ffffff" text="#000000">
    On 11/29/2010 1:53 PM, Ashley Sheridan wrote:
    <blockquote
      cite="mid:1291067598.14481.2.camel@localhost.localdomain"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <meta name="GENERATOR" content="GtkHTML/3.28.2">
      On Mon, 2010-11-29 at 10:40 -0800, Charles Pritchard wrote:
      <blockquote type="CITE">
        <pre>> Date: Sun, 28 Nov 2010 15:54:04 +0100
> From: Christoph P?per<<a moz-do-not-send="true" href="mailto:christoph.paeper@crissov.de">christoph.paeper@crissov.de</a>>
> To: whatwg group<<a moz-do-not-send="true" href="mailto:whatwg@lists.whatwg.org">whatwg@lists.whatwg.org</a>>
> Subject: Re: [whatwg] Exposing spelling/grammar suggestions in
>    contentEditable
> Message-ID:<<a moz-do-not-send="true" href="mailto:62959690-0E26-4BBC-AB4F-F9726F24CAF9@crissov.de">62959690-0E26-4BBC-AB4F-F9726F24CAF9@crissov.de</a>>
> 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:<<a moz-do-not-send="true" href="http://lists.w3.org/Archives/Public/www-style/2010Oct/0849.html">http://lists.w3.org/Archives/Public/www-style/2010Oct/0849.html</a>

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.

</pre>
      </blockquote>
      <br>
      <br>
      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?<br>
    </blockquote>
    <br>
    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.<br>
    <br>
    I do think it's reasonable to allow for a getSpellingRanges
    function.<br>
    <br>
    I don't find Benjamin's objections to be sufficient to block, given
    the existing scripting context:<br>
    1)  "Detecting the user's language (including fine distinctions like
    British/US English)."<br>
    and <br>
    2) "Fingerprinting the user's system. Different systems likely use<br>
    different dictionaries with different coverage. You could use<br>
    dictionary profiles to guess at the user's system (potentially down
    to<br>
    operating system and version)."<br>
    <br>
    Those are the two objections I heard to exposing spelling ranges
    inside of contenteditable.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    There were many other objections to exposing suggested spelling, and
    I think that's a very separate issue now than exposing the
    misspelled ranges.<br>
    <br>
    There are enough reasonable accessibility use cases to more strongly
    consider exposing something like getSpellingRanges(
    preferredLanguage )<br>
    <br>
    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.<br>
    <br>
    Vendors:<br>
    Can I get a maybe?<br>
    <br>
    -Charles<br>
  </body>
</html>