Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable

On Thu, 30 Dec 2010, Nils Dagsson Moskopp wrote: > Ian Hickson schrieb am Thu, 30 Dec 2010 01:47:51 + > (UTC): > > > > I am skeptical about allowing Web pages decide what should be in the > > context menu. Adding things is ok, but removing things leads to a > > broken user experience. For e

Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable

On Sat, Jan 1, 2011 at 7:12 AM, Benjamin Hawkes-Lewis wrote: > On Sat, Jan 1, 2011 at 1:23 AM, Charles Pritchard wrote: >> It is covered by the WAI ARIA 1.0 LC doc. > > Note this usage is waiting on a putative change to WAI-ARIA to define > its meaning when used with roles other than gridcell/opt

Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable

On Sat, Jan 1, 2011 at 1:23 AM, Charles Pritchard wrote: > It is covered by the WAI ARIA 1.0 LC doc. Note this usage is waiting on a putative change to WAI-ARIA to define its meaning when used with roles other than gridcell/option/row/tab. http://www.w3.org/WAI/PF/aria/states_and_properties#aria

[whatwg] Exposing spelling/grammar suggestions in contentEditable

Regarding: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-December/029559.html This has (somewhat) been resolved: Benjamin has pointed out that aria-invalid = "spelling|grammar" would work just fine with . It's simply not implemented by vendors at the moment. It is covered by the WAI

Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable

On Wed, Dec 29, 2010 at 11:01 PM, Nils Dagsson Moskopp wrote: > Ian Hickson schrieb am Thu, 30 Dec 2010 01:47:51 + > (UTC): > >> I am skeptical about allowing Web pages decide what should be in the >> context menu. Adding things is ok, but removing things leads to a >> broken user experience.

Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable

Ian Hickson schrieb am Thu, 30 Dec 2010 01:47:51 + (UTC): > I am skeptical about allowing Web pages decide what should be in the > context menu. Adding things is ok, but removing things leads to a > broken user experience. For example, as a user I frequently make use > of "view source", and

Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable

On Sat, 27 Nov 2010, Charles Pritchard wrote: > > Is there room for discussion of an API to expose misspelled ranges of > text in contentEditable? What's the use case? In practice, as far as I can tell, you'd either want the browser to handle all the spelling and grammar checking itself, or you

Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable

On Fri, Dec 3, 2010 at 10:05 AM, Adrian Sutton wrote: > Notably, users do not want the full browser context menu with some custom > additions (though obviously this would make a good option for some users) - > having "View Source" for example is quite damaging to the usability of rich > text edito

Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable

On 12/3/2010 2:19 PM, Adrian Sutton wrote: On 3 Dec 2010, at 22:06, Charles Pritchard wrote: Yes, I understand that. Your statement relates to a defect in the current flexibility of the "context menu". I fully understand that, you wouldn't need the context menu to be more flexible, if you h

Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable

On 12/2/2010 4:16 PM, Jonas Sicking wrote: On Thu, Dec 2, 2010 at 4:07 PM, Charles Pritchard wrote: 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 u

Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable

On 3 Dec 2010, at 22:06, Charles Pritchard wrote: > Yes, I understand that. > > Your statement relates to a defect in the current flexibility of the "context > menu". > > I fully understand that, you wouldn't need the context menu to be more > flexible, if you had access to suggestions, as you

Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable

On 12/3/2010 1:38 PM, Adrian Sutton wrote: On 3 Dec 2010, at 20:41, Charles Pritchard wrote: The major use case here remains being able to provide both spell checking as you type and a customised context menu within rich text editors. Today that is not possible on any browser that I know of a

Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable

On 12/3/2010 1:34 PM, Jonas Sicking wrote: There is a lot of push back on this list regarding IME: I'd like to know the boundaries of acceptable use cases. Well, it depends on how you look at it. Your "real" use case is that you want a webpage editor that supports IME, right? That is a very good

Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable

On 3 Dec 2010, at 20:41, Charles Pritchard wrote: >> The major use case here remains being able to provide both spell checking as >> you type and a customised context menu within rich text editors. Today that >> is not possible on any browser that I know of and it's one of if not the >> biggest

Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable

> There is a lot of push back on this list regarding IME: I'd like to know the > boundaries of acceptable use cases. Well, it depends on how you look at it. Your "real" use case is that you want a webpage editor that supports IME, right? That is a very good use case. Less good is "I want to build

Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable

On 12/3/2010 2:05 AM, Adrian Sutton wrote: On 3 Dec 2010, at 00:16, Jonas Sicking wrote: 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 imple

Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable

On 3 Dec 2010, at 00:16, Jonas Sicking wrote: > 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 major use c

Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable

On Mon, Nov 29, 2010 at 6:05 PM, Charles Pritchard wrote: > Has this list considered moving towards standards in 'chrome' extensions? Not to my recollection. > It > seems that there is a lot of low-hanging fruit > that, while not exposed to untrusted scripts, could easily be standardized > betwe

Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable

On Fri, Dec 3, 2010 at 12:07 AM, Charles Pritchard wrote: > 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 you make a spelling mis

Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable

On Thu, Dec 2, 2010 at 9:53 PM, Benjamin Hawkes-Lewis wrote: > Allowing UAs explicitly to provide information via dedicated optional > fields is different to requiring UAs them to leak it in the course of > providing another service (such as spelling). It's worth noting that in practice UAs have

Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable

On Thu, Dec 2, 2010 at 4:07 PM, Charles Pritchard wrote: > On 12/2/2010 4:00 PM, Aryeh Gregor wrote: >> >> On Thu, Dec 2, 2010 at 3:30 PM, Charles Pritchard  wrote: >>> >>> I can tell you, that blocking the issue does have real usability costs: >> >> I don't know if everyone here actually agrees w

Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable

On 12/2/2010 4:00 PM, Aryeh Gregor wrote: On Thu, Dec 2, 2010 at 3:30 PM, Charles Pritchard 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? Wha

Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable

On Thu, Dec 2, 2010 at 3:30 PM, Charles Pritchard 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 othe

Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable

On Thu, Dec 2, 2010 at 8:30 PM, Charles Pritchard wrote: > On 11/28/2010 11:30 PM, Benjamin Hawkes-Lewis wrote: >> >> Breaches would include: >> >>    1. Detecting the user's language (including fine distinctions like >> British/US English). >>    2. Fingerprinting the user's system. Different sys

Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable

On 11/28/2010 11:30 PM, Benjamin Hawkes-Lewis wrote: Breaches would include: 1. Detecting the user's language (including fine distinctions like British/US English). 2. Fingerprinting the user's system. Different systems likely use different dictionaries with different coverage. You could

Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable

Did my followup discussion further the case? Do you still feel that I've dismissed your comments regarding IME complexity? I think they were valuable, more as documentation than as cautionary examples... I did understand that you intended the latter, and I recognize the baseline of frustration

Re: [whatwg] Exposing spelling/grammar suggestions in

t: Re: [whatwg] Exposing spelling/grammar suggestions in >contentEditable > Message-ID:<62959690-0e26-4bbc-ab4f-f9726f24c...@crissov.de <mailto:62959690-0e26-4bbc-ab4f-f9726f24c...@crissov.de>> > Content-Type: text/plain; charset=us-ascii > > Charles Pritchard: &g

Re: [whatwg] Exposing spelling/grammar suggestions in

On Mon, Nov 29, 2010 at 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 > > To: whatwg group > > Subject: Re: [whatwg] Exposing s

Re: [whatwg] Exposing spelling/grammar suggestions in

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 > > To: whatwg group > > Subject: Re: [whatwg] Exposing spelling/grammar suggestions in > > contentEditable > > Message-I

Re: [whatwg] Exposing spelling/grammar suggestions in

Date: Sun, 28 Nov 2010 15:54:04 +0100 From: Christoph P?per To: whatwg group Subject: Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable Message-ID:<62959690-0e26-4bbc-ab4f-f9726f24c...@crissov.de> Content-Type: text/plain; charset=us-ascii Charles Pritchard:

Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable

On 11/28/2010 11:30 PM, Benjamin Hawkes-Lewis wrote: On Mon, Nov 29, 2010 at 4:19 AM, Charles Pritchard wrote: What breach is enabled by using a limited spell check? (What does “limited” mean?) If script can programmaticaly get at the spell check results, then it exposes whether particular wo

Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable

On 11/29/2010 1:49 AM, timeless wrote: On Mon, Nov 29, 2010 at 5:57 AM, Charles Pritchard wrote: A method for triggering a system/ua spell check via execCommand would be a small step forward. Is that something already available? Afaik, it was canned from the early MS model. Bringing up syste

Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable

On Sun, 28 Nov 2010 17:27:30 +0100, Adrian Sutton wrote: On 28 Nov 2010, at 15:52, Benjamin Hawkes-Lewis wrote: On Sun, Nov 28, 2010 at 3:41 PM, Adrian Sutton wrote: User's expect a rich text editor to override the browser default context menu to provide things like properties for images,

Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable

On Mon, Nov 29, 2010 at 5:57 AM, Charles Pritchard wrote: > A method for triggering a system/ua spell check via execCommand > would be a small step forward. Is that something already available? > Afaik, it was canned from the early MS model. Bringing up system dialogs is scary/surprising and co

Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable

Am 28.11.2010 17:27 schrieb Adrian Sutton: On 28 Nov 2010, at 15:52, Benjamin Hawkes-Lewis wrote: On Sun, Nov 28, 2010 at 3:41 PM, Adrian Sutton mailto:adrian.sut...@ephox.com>> wrote: User's expect a rich text editor to override the browser default context menu to provide things like propertie

Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable

On Mon, Nov 29, 2010 at 4:19 AM, Charles Pritchard wrote: >>> What breach is enabled by using a limited spell check? >> >> (What does “limited” mean?) >> >> If script can programmaticaly get at the spell check results, then it >> exposes whether particular words are in the user’s dictionary to tha

Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable

In thread. On Nov 28, 2010, at 8:03 PM, Cameron McCormack wrote: > Charles Pritchard: >> The content within an editable area is already exposed: xhr is >> available. > > That is data that the user has explicitly typed in, though. Yes, that's what I meant to point out by the statement. > >> I

Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable

Charles Pritchard: > The content within an editable area is already exposed: xhr is > available. That is data that the user has explicitly typed in, though. > I understand that a 'custom' system dictionary could expose > private data ... Just as 'suggestions' on form elements do. Suggestions on

Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable

A method for triggering a system/ua spell check via execCommand would be a small step forward. Is that something already available? Afaik, it was canned from the early MS model. On Nov 28, 2010, at 6:56 PM, Oliver Hunt wrote: > It _may_ be worth discussing (as I am not all knowing) but I c

Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable

And now it's being brought up in the context of content editable. My understanding of prior conversations were that contentEditable is a reasonable method to explore input editing. The content within an editable area is already exposed: xhr is available. I understand that a 'custom' system dict

Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable

It _may_ be worth discussing (as I am not all knowing) but I cannot see a way that these APIs could be added without opening up a user to privacy violations. It is somewhat irksome to me that I have raised these exact issues in the past in the context of implementing editors in canvas and you a

Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable

On Sun, Nov 28, 2010 at 4:27 PM, Adrian Sutton wrote: > It could, but it doesn't. Any browser that tried doing that would likely > just run into compatibility complaints and have to revert it. Can you give an example of an incompatibility this would introduce? -- Benjamin Hawkes-Lewis

Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable

On 28 Nov 2010, at 15:52, Benjamin Hawkes-Lewis wrote: > On Sun, Nov 28, 2010 at 3:41 PM, Adrian Sutton > wrote: >> User's expect a rich text editor >> to override the browser default context menu to provide things like >> properties for images, lists, tables etc and the other stuff usually found

Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable

On Sun, Nov 28, 2010 at 3:41 PM, Adrian Sutton wrote: > User's expect a rich text editor > to override the browser default context menu to provide things like > properties for images, lists, tables etc and the other stuff usually found > in a rich text editor's context menu.  However, once that is

Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable

On 28 Nov 2010, at 14:54, Christoph Päper wrote: > 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:

Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable

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:

Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable

On Sun, Nov 28, 2010 at 12:32 PM, Ashley Sheridan wrote: > But why would a password field ever be tied to a contentEditable section? I did not say that was the source of password data that was learned by the spell checker. I said that a spell checker could learn passwords. In fact on the platfo

Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable

On Sun, 2010-11-28 at 11:27 +0200, timeless wrote: > On Sat, Nov 27, 2010 at 10:19 PM, Charles Pritchard wrote: > > Is there room for discussion of an API > > there's room to discuss such things. > > > to expose misspelled ranges of text in contentEditable? > > I'm worried about privacy risks.

Re: [whatwg] Exposing spelling/grammar suggestions in contentEditable

On Sat, Nov 27, 2010 at 10:19 PM, Charles Pritchard wrote: > Is there room for discussion of an API there's room to discuss such things. > to expose misspelled ranges of text in contentEditable? I'm worried about privacy risks. Some devices have a tendency to learn passwords as typed words, ot

[whatwg] Exposing spelling/grammar suggestions in contentEditable

Is there room for discussion of an API to expose misspelled ranges of text in contentEditable? This would be building upon the spelling and grammar checking section: http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#spelling-and-grammar-checking A method for a contentEdit