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

[Ian Hickson]

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 example, as a user I frequently make use 
> > of "view source", and I don't think it would be good for a page to be 
> > able to remove that feature.
> 
> For the record, crippling context menus is in the wild already: Youtube 
> has no “save to disk” (or any other of the standard options) on a 
> HTML5 video, only „about HTML5“.

Granted, but that doesn't mean we should make it worse. Better to remove 
such possibilities first (which is what  is about enabling).


On Wed, 29 Dec 2010, Glenn Maynard wrote:
> 
> One possible UI: pushing options into a separate menu block.  For 
> example, XP's start menu does this; less-used items are hidden until you 
> click an arrow at the bottom of the list to expand the full menu. This 
> would allow sites to set up their own context menu items without a lot 
> of clutter, but disallow them from completely disabling the existing 
> one.
> 
> I'm not sure whether pages hinting whether to do this would be 
> meaningful, since context menu presentation varies wildly and the 
> desired hint may be different for each browser.  This may be better left 
> to browser extensions.

This is one of the possible ways to implement /contextmenu=. I look 
forward to implementation experience for these features to guide future 
work along these lines.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

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

[Benjamin Hawkes-Lewis]

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/option/row/tab.
>
> http://www.w3.org/WAI/PF/aria/states_and_properties#aria-selected

Sorry for the noise - as was pointed out to me off-list, OP was
referring to aria-invalid which doesn't have this problem.

--
Benjamin Hawkes-Lewis

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

[Benjamin Hawkes-Lewis]

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-selected

--
Benjamin Hawkes-Lewis

[whatwg] Exposing spelling/grammar suggestions in contentEditable

[Charles Pritchard]

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 ARIA 1.0 LC doc.

somebody [mark aria-invalid="spelling"]mispeld[/mark] this text.

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

[Glenn Maynard]

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. For example, as a user I frequently make use
>> of "view source", and I don't think it would be good for a page to be
>> able to remove that feature.

One possible UI: pushing options into a separate menu block.  For
example, XP's start menu does this; less-used items are hidden until
you click an arrow at the bottom of the list to expand the full menu.
This would allow sites to set up their own context menu items without
a lot of clutter, but disallow them from completely disabling the
existing one.

I'm not sure whether pages hinting whether to do this would be
meaningful, since context menu presentation varies wildly and the
desired hint may be different for each browser.  This may be better
left to browser extensions.

> For the record, crippling context menus is in the wild already: Youtube
> has no “save to disk” (or any other of the standard options) on a HTML5
> video, only „about HTML5“.

They seem to think that sabotaging the user's browser is a joke, too,
since there's a rickrolling "save video as" menu item.  Not funny.

I don't understand why most browsers honor preventDefault on
contextmenu and right-clicks by default.  Blatent abuse like this is
widespread, and one of the oldest, more obnoxious and most common
scripting abuses--alert("Right click is not allowed")--so it gets
turned off by users who know how.  But since it's on by default, many
sites try to use it--innocently, mostly--to override the context menu
for site features.  This means that whether you enable it or disable
it, some sites are broken, often with that nonsensical behavior of two
menus opening on top of each other.

This can't be prevented entirely, eg. blitting images and video into a
canvas will always break associated context menu items, but
fragmenting browser behavior so badly is a general, user-visible
problem.

-- 
Glenn Maynard

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

[Nils Dagsson Moskopp]

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 I don't think it would be good for a page to be
> able to remove that feature.

For the record, crippling context menus is in the wild already: Youtube
has no “save to disk” (or any other of the standard options) on a HTML5
video, only „about HTML5“.

-- 
Nils Dagsson Moskopp // erlehmann



signature.asc
Description: PGP signature

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

[Ian Hickson]

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'd want to do it all 
yourself. This would argue for an on/off switch for UA-provided checking, 
which indeed is available (the spellcheck="" attribute), and for ARIA 
exposure of the "spelling mistake" semantic, which is also available.


On Thu, 2 Dec 2010, Charles Pritchard wrote:
> 
> 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.

Doesn't letting the UA take care of this adequately address this use case? 
If not, why not?


This may be an opportune time to remind everyone that there is a 
process for adding new features, and it begins with establishing use 
cases, researching existing solutions, and testing possible ideas:

   
http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F


On Fri, 3 Dec 2010, Adrian Sutton 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 selling point for our non-JavaScript 
> editor (we offer both Java applet and Javascript based editors).

Insofar as extending context menus is concerned, that's not a 
spelling/grammar checking issue, it's a context menu issue -- and one that 
is resolved by the contextmenu=""/ feature in the spec.


> 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 editors since it would display a read-only source 
> without running the editors source filtering, as opposed to the editor's 
> built in source view which filters correctly and is editable.  There are 
> also styling considerations which are addressed quite well with the 
> current oncontextmenu handler and using pure HTML but which would likely 
> become quite difficult when trying to integrate with a browser's native 
> menu.

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 I don't think it would be good for a page to be able to 
remove that feature.


On Mon, 29 Nov 2010, Charles Pritchard wrote:
>
> Currently, there's no way for an author to markup spelling errors in 
> text. A [spelling] tag would address that deficiency.
> 
> This could be used for a number of reasons, from [sic]-style 
> annotations, to conveying to the user that an area is misspelled using 
> the same visual cues as contenteditable.
> 
> At this point, it'd simply be a semantic element. If there's any 
> traction, we could certainly talk about additional attributes or another 
> name, such as sic: [sic]misspeld[/sic]
> 
> Does the list need further use cases for its consideration?

_Any_ use cases would be a start. :-)

What's the problem you're trying to solve?


On Tue, 30 Nov 2010, Martin Janecke wrote:
> 
> I support this idea and I'd certainly use it. For example, I'm currently 
> copying an old rhyme book to hypertext and would love to mark 
> historically correct (but now incorrect) spelling, spelling 
> intentionally done wrong for better rhyming (yes, people did this in the 
> past) and unintentional errors from the book semantically. I think it is 
> important to note where those errors are done intentional (by me, the 
> publisher of the web page) in contrast to errors accidentally added by 
> me that differ from the copied book.

 is the element for this purpose.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

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

[Benjamin Hawkes-Lewis]

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 editors since it would display a read-only source without running the
> editors source filtering, as opposed to the editor's built in source view
> which filters correctly and is editable.

If "View Source" is verifiably damaging to the usability of rich text
editors then isn't it damaging to the usability of "contenteditable"
everywhere, and shouldn't it be fixed at the UA level rather than left
to individual websites to work around?

Safari and Chrome do not show the "View Source" option when you click
on "contenteditable" (or other text content).

Safari does not show "Inspect Element" either unless you enable the
"Developer" menu.

--
Benjamin Hawkes-Lewis

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

[Charles Pritchard]

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 had access to suggestions, as you have your own 
custom context menu implemented.


That's not the way I see it.  Right now I'm perfectly happy with the 
complete flexibility I have in the context menu. I don't want to try 
and tie in with the browser's context menu because that will reduce 
the flexibility.
I don't think it's fair to assume defeat; the context menu is a high 
level construct it is works as a security mechanism, much like drag and 
drop does.


You have a lot of flexibility with presentation. You do not have 
flexibility with the security model.


Recognizing that "suggestions" can not be shared with the DOM, the 
alternative is to address defects in the context menu.


It seems to me that were the context menu more easily manipulated via 
scripting, your use requirement (having suggestions) would be handled 
without exposing the suggestions to the DOM.


If I were able to script the context menu, and the context menu 
contains the spelling suggestions then the spelling suggestions are 
effectively in the DOM.
You'd be able to add and remove elements, but not "peek" at the content 
within a pre-existing element.


That is, you wouldn't know that "View source..." says View source; you 
would be able to deactivate it though,

whatever it's caption reads.


Still, your use case does require that spelling ranges be made available.


If I use the current approach of replacing the context menu then yes. 
 If I'm scripting an existing context menu then no - if it's a 
spelling error the suggestions will already be in the context menu and 
I won't need to do anything special with them (but I would have to 
remove every *other* menu and add my own custom ones).


I really don't see why if spelling suggestions are a security/privacy 
concern this couldn't be an opt-in feature like local storage is. That 
said, I've also not been convinced of the privacy or security concerns 
beyond just making sure you don't run a buggy/insecure spell checker 
(much like you shouldn't run a buggy/insecure browser).  As has been 
noted, the information such as user language and OS/Browser type is 
pretty trivial to determine through a range of other means.

The possibility of fishing out saved information is too great.

I might for instance, script a set of numbers, and if you've added it to 
your suggestions, I could get your home address.


The window for abuse by exposing only the text range is much smaller.

Again, I'd say that your issue is about context menus. You are using a 
completely custom context menu: but it is still a context menu.


This technical distinction is important for long term work. Consider 
that your context menu may be run in a sandbox.
Think something like WebWorkers, but with only unidirectional 
communication, and a limited dom.


As for the privacy issue on exposing suggestions: I think that there 
should be a reasonable amount of caution.
Yes, spelling suggestions could be a privacy setting, but I think you're 
more likely to see it as a security setting with browser extensions, and 
not in the untrusted window DOM.

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

[Charles Pritchard]

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 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


I'd like to see a selector like that for the form fields [textarea] and 
[input type="text"].

It would not introduce any security breaches mentioned in this thread,
if it were limited to those two fields.

I believe it was discussed on www-style in part.

I'd certainly like to see it happen: is there disagreement on this list 
about such a selector existing?


-Charles

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

[Adrian Sutton]

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 have your own custom 
> context menu implemented.

That's not the way I see it.  Right now I'm perfectly happy with the complete 
flexibility I have in the context menu. I don't want to try and tie in with the 
browser's context menu because that will reduce the flexibility.

> Recognizing that "suggestions" can not be shared with the DOM, the 
> alternative is to address defects in the context menu.
> 
> It seems to me that were the context menu more easily manipulated via 
> scripting, your use requirement (having suggestions) would be handled without 
> exposing the suggestions to the DOM.

If I were able to script the context menu, and the context menu contains the 
spelling suggestions then the spelling suggestions are effectively in the DOM.

> Still, your use case does require that spelling ranges be made available.


If I use the current approach of replacing the context menu then yes.  If I'm 
scripting an existing context menu then no - if it's a spelling error the 
suggestions will already be in the context menu and I won't need to do anything 
special with them (but I would have to remove every *other* menu and add my own 
custom ones).

I really don't see why if spelling suggestions are a security/privacy concern 
this couldn't be an opt-in feature like local storage is. That said, I've also 
not been convinced of the privacy or security concerns beyond just making sure 
you don't run a buggy/insecure spell checker (much like you shouldn't run a 
buggy/insecure browser).  As has been noted, the information such as user 
language and OS/Browser type is pretty trivial to determine through a range of 
other means.

Regards,

Adrian Sutton.
__
Adrian Sutton, CTO
UK: +44 1 628 353 032
Ephox http://www.ephox.com/
Ephox Blogs http://people.ephox.com/, Personal Blog http://www.symphonious.net/

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

[Charles Pritchard]

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 
and it's one of if not the biggest selling point for our 
non-JavaScript editor (we offer both Java applet and Javascript 
based editors).  This use case would require providing spelling 
suggestions, not just identifying the location of spelling errors.


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 editors since it would display a 
read-only source without running the editors source filtering, as 
opposed to the editor's built in source view which filters correctly 
and is editable.  There are also styling considerations which are 
addressed quite well with the current oncontextmenu handler and 
using pure HTML but which would likely become quite difficult when 
trying to integrate with a browser's native menu.


What further information do you require around this use case?


Adrian:

Adding items to the context menu is not something that vendors are 
quite ready for, with their code bases. They're on their way: the 
resulting context menu would allow you to add items to the UAs menu. 
At some point an API may develop to style and/or script the context 
menu.  This is a limitation until context menus are more flexible.


Allow me to reiterate:
Notably, users do not want the full browser context menu with some 
custom additions ... - having "View Source" for example is quite 
damaging to the usability of rich text editors ...


It is possible today to replace the context menu with a custom one and 
this works incredibly well for a usability perspective. I don't see a 
need to change this.


It is also possible today for rich text editors to have the built-in 
browser spell checker mark any spelling errors. I don't see a need to 
change this.


What isn't possible is to have the combination of spell checking as 
you type suggestions with a custom context menu. Inline spell checking 
with right-click for suggestions has become almost the exclusive way 
that authors use spell checkers. I regularly and repeatedly encounter 
clients and prospective clients who are prepared to spend significant 
amounts of money to solve this problem (by purchasing a non-JavaScript 
based editor).




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 have your own custom 
context menu implemented.


Recognizing that "suggestions" can not be shared with the DOM, the 
alternative is to address defects in the context menu.


It seems to me that were the context menu more easily manipulated via 
scripting, your use requirement (having suggestions) would be handled 
without exposing the suggestions to the DOM.


Still, your use case does require that spelling ranges be made available.

-Charles

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

[Charles Pritchard]

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 use case.

Less good is "I want to build an IME implementation in canvas". As in,
why do you limit yourself to a particular technology? It's equally bad
to say "I want to display a png image, using a giant  with
pixel-sized cells".
I'm in full agreement about your second clause: "why do you limit 
yourself to a particular technology?".


I've no intention of being limited, I use as much of the standard 
software stack as I can,
I use as wide of a profile as I can afford, to support a broad range of 
devices.


The "real" use case you outlined seems irrelevant. We need general, 
acceptable use cases.


My "real" use case is developing better APIs for web applications, as 
that's what I specialize in.
When APIs are absent, we end up needing to cut features or implementing 
them with an ad-hoc spec.


The whatwg work-product saves me a lot of money and time in project 
management.

My "use case" is the presence of a standard behavior.


I'd like to have a technical discussion on the merits of the API, not a
political/philosophical one on UA-Author control.

My current understanding is this:
Use cases which involve implementing IME with [canvas] are inappropriate at
this time.
This is based on my understanding of comments by Oliver, Ian and Roc.

The sticking point here is that canvas doesn't seem like the best
solution to the use case of building an editor. We already have
contentEditable as a better solution for that. So APIs that are only
needed for editors doesn't seem like useful addition to canvas.

That's a limited view on what an editor may be.
Would you agree that APIs that are needed for editors ARE a useful 
addition to contentEditable behavior?


I'm an application designer. We don't exactly "wait" for a better IME to 
come out.
Existing IMEs for pen input are lacking, current contentEditable 
implementations

do not take InkML into account, and there's been no commitment from vendors.

Further, we can prototype it without their support. If support does 
develop, then we have a backward compatible solution.
If we can develop a subset of APIs in the meantime, that makes our job 
easier, as we have a spec to follow,
and it makes it easier to make our app gracefully degrade, as a subset 
of functionality could be available in the UA.



Use cases which can be solved by filing defects with the UA -may- not be
appropriate.
This is based on my understanding of comments by Benjamin and Aryeh.

Indeed. Saying "Browser X has some bugs in their implementation of
feature Y. Lets add feature Z and hope they implement without bugs"
isn't very sound logic. Unless you have strong reasons to believe that
browser X are opposed to fixing the bugs in feature Y, but that they
would implement feature Z without bugs.
I think that additional usability bugs should be filed. But I see it as 
a separate issue

from developing API support for custom controls. We work with all major UAs,
API availability is more of a focus for us than how the UA has decided 
to present itself.




My counter-argument is well-defined by UAAG 2.0:
"2.1.5 Write Access: If the user can modify the state or value of a piece of
content through the user interface (e.g., by checking a box or editing a
text area), the same degree of write access is available programmatically.
(Level A)".

With due respect for privacy and security:
"Some of the requirements of this document may have security implications,
such as communication through APIs, and allowing programmatic read and write
access to content and user interface control. This document assumes that
features required by this document will be built on top of an underlying
security architecture. Consequently, unless permitted explicitly in a
success criterion, this document grants no conformance exemptions based on
security issues."

Indeed. Privacy and security trumps most things, including UAAG.

That quote is from the UAAG.

There are many items I've brought up, regarding IME and even Canvas, 
which do fall under the "Write Access" clause, that are not
privacy / security issues, but have still been shut down by members of 
this list.



But like so many things in standards work, it comes down to judgement
calls. There are few hard and fast rules, only rules of thumb.
Cost is always a factor. I've tried to bring to this group low cost 
solutions to address deficiencies in existing APIs.
They've met with some strong resistance: I'm doing my best to re-tailor 
use cases to something more palatable to the group.

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

[Adrian Sutton]

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 selling point for our non-JavaScript editor (we offer both Java 
>> applet and Javascript based editors).  This use case would require providing 
>> spelling suggestions, not just identifying the location of spelling errors.
>> 
>> 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 editors since it would display a read-only source without running the 
>> editors source filtering, as opposed to the editor's built in source view 
>> which filters correctly and is editable.  There are also styling 
>> considerations which are addressed quite well with the current oncontextmenu 
>> handler and using pure HTML but which would likely become quite difficult 
>> when trying to integrate with a browser's native menu.
>> 
>> What further information do you require around this use case?
> 
> Adrian:
> 
> Adding items to the context menu is not something that vendors are quite 
> ready for, with their code bases. They're on their way: the resulting context 
> menu would allow you to add items to the UAs menu. At some point an API may 
> develop to style and/or script the context menu.  This is a limitation until 
> context menus are more flexible.

Allow me to reiterate:
>> Notably, users do not want the full browser context menu with some custom 
>> additions ... - having "View Source" for example is quite damaging to the 
>> usability of rich text editors ...


It is possible today to replace the context menu with a custom one and this 
works incredibly well for a usability perspective. I don't see a need to change 
this.

It is also possible today for rich text editors to have the built-in browser 
spell checker mark any spelling errors. I don't see a need to change this.

What isn't possible is to have the combination of spell checking as you type 
suggestions with a custom context menu. Inline spell checking with right-click 
for suggestions has become almost the exclusive way that authors use spell 
checkers. I regularly and repeatedly encounter clients and prospective clients 
who are prepared to spend significant amounts of money to solve this problem 
(by purchasing a non-JavaScript based editor).

Regards,

Adrian Sutton.
__
Adrian Sutton, CTO
UK: +44 1 628 353 032
Ephox http://www.ephox.com/
Ephox Blogs http://people.ephox.com/, Personal Blog http://www.symphonious.net/

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

[Jonas Sicking]

> 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 an IME implementation in canvas". As in,
why do you limit yourself to a particular technology? It's equally bad
to say "I want to display a png image, using a giant  with
pixel-sized cells".

> I'd like to have a technical discussion on the merits of the API, not a
> political/philosophical one on UA-Author control.
>
> My current understanding is this:
> Use cases which involve implementing IME with [canvas] are inappropriate at
> this time.
> This is based on my understanding of comments by Oliver, Ian and Roc.

The sticking point here is that canvas doesn't seem like the best
solution to the use case of building an editor. We already have
contentEditable as a better solution for that. So APIs that are only
needed for editors doesn't seem like useful addition to canvas.

> Use cases which can be solved by filing defects with the UA -may- not be
> appropriate.
> This is based on my understanding of comments by Benjamin and Aryeh.

Indeed. Saying "Browser X has some bugs in their implementation of
feature Y. Lets add feature Z and hope they implement without bugs"
isn't very sound logic. Unless you have strong reasons to believe that
browser X are opposed to fixing the bugs in feature Y, but that they
would implement feature Z without bugs.

> My counter-argument is well-defined by UAAG 2.0:
> "2.1.5 Write Access: If the user can modify the state or value of a piece of
> content through the user interface (e.g., by checking a box or editing a
> text area), the same degree of write access is available programmatically.
> (Level A)".
>
> With due respect for privacy and security:
> "Some of the requirements of this document may have security implications,
> such as communication through APIs, and allowing programmatic read and write
> access to content and user interface control. This document assumes that
> features required by this document will be built on top of an underlying
> security architecture. Consequently, unless permitted explicitly in a
> success criterion, this document grants no conformance exemptions based on
> security issues."

Indeed. Privacy and security trumps most things, including UAAG.

But like so many things in standards work, it comes down to judgement
calls. There are few hard and fast rules, only rules of thumb.

/ Jonas

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

[Charles Pritchard]

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
implement your suggestion.


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 selling point for our non-JavaScript 
editor (we offer both Java applet and Javascript based editors).  This 
use case would require providing spelling suggestions, not just 
identifying the location of spelling errors.


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 editors since it would display a read-only 
source without running the editors source filtering, as opposed to the 
editor's built in source view which filters correctly and is editable. 
 There are also styling considerations which are addressed quite well 
with the current oncontextmenu handler and using pure HTML but which 
would likely become quite difficult when trying to integrate with a 
browser's native menu.


What further information do you require around this use case?


Adrian:

Adding items to the context menu is not something that vendors are quite 
ready for, with their code bases. They're on their way: the resulting 
context menu would allow you to add items to the UAs menu. At some point 
an API may develop to style and/or script the context menu.  This is a 
limitation until context menus are more flexible.


I'd like to focus on exposing ranges, and I think that a more limited 
use case would benefit your users sooner.


Jonas:

I've outlined use cases, and I'm certainly willing to author the usual 
use "stories".


There is a lot of push back on this list regarding IME: I'd like to know 
the boundaries of acceptable use cases.
I'd like to have a technical discussion on the merits of the API, not a 
political/philosophical one on UA-Author control.


My current understanding is this:
Use cases which involve implementing IME with [canvas] are inappropriate 
at this time.

This is based on my understanding of comments by Oliver, Ian and Roc.

Use cases which can be solved by filing defects with the UA -may- not be 
appropriate.

This is based on my understanding of comments by Benjamin and Aryeh.

My counter-argument is well-defined by UAAG 2.0:
"2.1.5 Write Access: If the user can modify the state or value of a 
piece of content through the user interface (e.g., by checking a box or 
editing a text area), the same degree of write access is available 
programmatically. (Level A)".


With due respect for privacy and security:
"Some of the requirements of this document may have security 
implications, such as communication through APIs, and allowing 
programmatic read and write access to content and user interface 
control. This document assumes that features required by this document 
will be built on top of an underlying security architecture. 
Consequently, unless permitted explicitly in a success criterion, this 
document grants no conformance exemptions based on security issues."


All:

Use case: An online college course, using simple forum based software 
would like to include a spell checking button as part of a progressively 
enhanced contentEditable/textarea form area.
They would also like to allow users to set a preference to be warned if 
their post contains spelling mistakes before posting.


Reasoning: Get range would allow for counting if there are spelling 
mistakes.


Use case: A software suite for reviewing articles for publishing 
includes a step-by-step proofing mechanism for articles. One step 
involves checking for misspellings:
the application would display mis-spelled ranges within an active, 
styled node, where the user continues to focus, and continues to hit 
"next/ignore/add".


Reasoning: Copying the text content to a stylized area allows the user 
to maintain focus in an active area, instead of scrolling through a page 
themselves.
A similar mechanism might scroll the page for them, bringing the 
misspelled range into view. In the case of editing, it may be very 
inappropriate to "Add"
misspelled words to the system dictionary, but quite helpful to have 
them in a custom dictionary maintained by the application, in reference 
to the particular

article, author, subject or other item.

Those two use cases, I hope, fall within the guidelines as I currently 
understand them.



Here's the start of a more formal proposal:

getSpellingRanges
getSpellingRanges should accept an optional locale string, and some 
implementations MAY require such a locale string to be set.

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

[Adrian Sutton]

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 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 
selling point for our non-JavaScript editor (we offer both Java applet and 
Javascript based editors).  This use case would require providing spelling 
suggestions, not just identifying the location of spelling errors.

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 editors since it would display a read-only source without running the 
editors source filtering, as opposed to the editor's built in source view which 
filters correctly and is editable.  There are also styling considerations which 
are addressed quite well with the current oncontextmenu handler and using pure 
HTML but which would likely become quite difficult when trying to integrate 
with a browser's native menu.

What further information do you require around this use case?

Regards,

Adrian Sutton.
__
Adrian Sutton, CTO
UK: +44 1 628 353 032
Ephox http://www.ephox.com/
Ephox Blogs http://people.ephox.com/, Personal Blog http://www.symphonious.net/

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

[Benjamin Hawkes-Lewis]

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
> between vendors supporting the Widgets spec.

I think there's room for convergence of extension/widget APIs,
including perhaps additions to the regular DOM APIs that are only
available to trusted code.

While ideally defects in systems IMEs would be fixed at the system
level, workarounds at the extension level would at least work with all
text entry controls across the web, rather than just individual sites.

I think groups who should be involved in a discussion around API
convergence include CommonJS and the GreaseMonkey community.

--
Benjamin Hawkes-Lewis

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

[Benjamin Hawkes-Lewis]

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 mistake in a textarea in Safari on Mac, the
squiggly line will scale with the text or the system zoom, it will
change colors with contrast settings, and you can check for and jump
to spelling mistakes with VoiceOver.

Where accessibility features are missing, bug reports can be filed
with the IME provider.

It might also be worth documenting techniques for accessible IMEs in UAAG.

--
Benjamin Hawkes-Lewis

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

[Benjamin Hawkes-Lewis]

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 identifying traits that
can leak through feature/bug detection (e.g. "typeof opera", testing
if vendor-prefixed styles are applied, conditional comments and
compilation, and so forth). In the case of UAs like Konqueror and
Internet Explorer, UA identification is a good proxy for OS detection
too. Other than helping and encouraging privacy-conscious users to
disable untrusted JS, I don't think UAs can do much about that.

To a lesser extent, such traits are also an issue at the HTTP level.

--
Benjamin Hawkes-Lewis

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

[Jonas Sicking]

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 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

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

[Charles Pritchard]

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?  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.

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.

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

[Aryeh Gregor]

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 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.

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

[Benjamin Hawkes-Lewis]

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 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).
>
> I haven't seen a response on these issues: They're currently exposed via
> window.navigator,
> so I'm just having a hard time seeing what the push-back is actually about.

Note 1: I'm not taking a position here on the appropriateness of
leaking this information.

Note 2: I do not claim any special security expertise.

Some UAs leak language on "navigator.language", but it is not part of
any (proposed or actual) specification AFAIK.

While the user's system /might/ be exposed by "navigator", the HTML5
draft specifically allows standard blank returns or misinformation, so
long as it's not inconsistent with the User-Agent header:

http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#client-identification

At the HTTP layer by "Accept-Language" or "User-Agent" headers might
leak the same information, but both are optional.

HTTP 1.1 warns that: "It might be contrary to the privacy expectations
of the user to send an Accept-Language header with the complete
linguistic preferences of the user in every request".

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.4

While HTTP 1.1 says UAs "SHOULD" send a User-Agent header, privacy
concerns are arguably a legitimate exclusion to that SHOULD.

UAs are of course notorious for lying in their User-Agent header for
compatibility reasons.

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).

> I think a good case was made for NOT exposing actual spelling suggestions. I
> haven't heard one regarding exposing DOM ranges for mis-spelled text.
> Limitations of the  element to a single range, is a
> reasonable issue..

Since you can populate and retrieve the text of a DOM range, what
difference would this make to security?

In one of your other emails, you mentioned establishing high arbitrary
limits on the number of calls to the spelling API (e.g. 1000) to
protect against abuse.

I suspect you would not need 1000 queries to identify language or
systems by dictionary - you just need to know the critical identifying
differences in advance?

In any case, if you had an API that told you the misspelled ranges
with one query, could you not supply an input DOM with 2000 words to a
single query, in order to build a dictionary profile? Perhaps I'm
misunderstanding your proposal here?

> Has there been a fundamental discussion about security regarding locale
> fingerprinting?
>
> At this point, we're talking about language codes as a level of personal
> privacy we reserve for a person's name, home address, etc.

That's a bit of a strawman.

Identifying a potential breach is not the same as equating the
seriousness of that breach with other potential breaches.

For myself, I wouldn't say leaking a system plus locale is as bad as
leaking a home address, for example.

> Has this point, and the potential for abuse, actually been discussed by 
> experts?

Perhaps these meet that bar:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html#sec15.1.4

http://panopticlick.eff.org/browser-uniqueness.pdf

http://www.schneier.com/blog/archives/2010/01/tracking_your_b.html

FWIW, for one implementor perspective, WebKit's Maciej has said (of
exposing navigator.acceptLanguage): "I think the privacy concern is
minimal".

http://www.mail-archive.com/webkit-...@lists.webkit.org/msg07686.html

> I can tell you, that blocking the issue does have real usability costs:

Would you agree those usability costs are:

   - If using a webservice for spellchecking, the user might be shown
words as misspelt that they have already added to their system
dictionary.
   - Spellchecking-on-demand would be subject to connection speed.
   - Web applications providing their own spelling UI backed by a
webservice would need to provide the browser's UI backed by the
browser's spelling service when offline.

(You mentioned clientside storage as another possibility; I doubt you
get enough storage for whole dictionaries, however.)

Have I missed anything out?

> blocking the issue without expert review, means that we're weighing actual,
> measurable usability costs with perceived insecurities. That doesn't seem
> reasonable to me.

You mention measuring and weighing. What metrics would you propose?
How would you balance them?

> FWIW: It's reasonably simple to use a minimum of scripting code to detect an
> input language, given only a sentence or two of data.

Indeed. However:

   

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

[Charles Pritchard]

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 use
dictionary profiles to guess at the user's system (potentially down to
operating system and version).


I haven't seen a response on these issues: They're currently exposed via 
window.navigator,

so I'm just having a hard time seeing what the push-back is actually about.

I think a good case was made for NOT exposing actual spelling 
suggestions. I haven't heard one regarding exposing DOM ranges for 
mis-spelled text.
Limitations of the  element to a single range, is a 
reasonable issue..


But what is with these two above? They've been echoed, and seem to be 
more of a devil's advocate argument than

one rooted in evidence.


Has there been a fundamental discussion about security regarding locale 
fingerprinting?


At this point, we're talking about language codes as a level of personal 
privacy we reserve for a person's name, home address, etc. Has this 
point, and the potential for abuse, actually been discussed by experts?


I can tell you, that blocking the issue does have real usability costs: 
blocking the issue without expert review, means that we're weighing 
actual, measurable usability costs with perceived insecurities. That 
doesn't seem reasonable to me.


FWIW: It's reasonably simple to use a minimum of scripting code to 
detect an input language, given only a sentence or two of data. I 
understand that there are situations where language use is regulated, 
but those situations carry so many other reductions in freedom: I highly 
doubt that exposing input locale would be anything but trivial in 
comparison to other issues. And window.navigator already carries this 
data, for the most part.


Input locale is being discussed on www-dom for text entry.


Can I get some further, reasonable discussion, on this issue? It's fine 
that Benjamin brought up that such data could be exposed,
but when looked at in context of the current scripting environment: that 
data is already exposed.


-Charles

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

[Charles Pritchard]

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 that my perspective brings.



On Nov 28, 2010, at 6:56 PM, Oliver Hunt  wrote:

> 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 
> appear to have chosen to ignore me.
> 
> --Oliver
> 
> On Nov 27, 2010, at 12:19 PM, Charles Pritchard wrote:
> 
>> 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 contentEditable section, along the lines of 
>> getSpellcheckRanges() would allow for content editors,
>> to stylize and provide further UI controls around spell checking. Such an 
>> API could be used to warn the user that
>> they have possibly misspelled text, in a similar way to how word processors 
>> convey the information.
>> 
>> It may not be feasible at the moment, but it could be worth some discussion. 
>> A Range list seems appropriate, though
>> it would need something along the lines of getSuggestedSpelling() on each 
>> range.
>> 
>> 
>> -Charles
>> 
> 

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

[Charles Pritchard]

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 words are in the user’s dictionary to that
page.

Limited, meaning not particular to a user's dictionary.

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 use
dictionary profiles to guess at the user's system (potentially down to
operating system and version).
This information is already exposed to varying degrees. Still, I do see 
your point.



Also your proposed limitation might well require user agents on some
platforms to implement their own dictionary service as opposed to
using platform dictionary services.

For example, say you were building a user agent for OS X. AFAICT you
can't exclude the user's dictionary when querying the system
spellchecking API:

http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSSpellChecker_Class/Reference/Reference.html#//apple_ref/doc/uid/2378
Good point.  How "damaging" do you consider exposing a 
getSpellcheckRanges() option?

I'm not speaking to listing spellcheck suggestions, just to ranges.

As you've noted, doing so would expose the user's language, and could be 
used to detect and distinguish system dictionaries.

If you don't need the user's dictionary or the same spellchecking UI,
you could disable spellchecking with the "spellcheck" attribute and
roll your own over XHR/web sockets.

http://www.w3.org/TR/html5/editing.html#spelling-and-grammar-checking
Can also roll one with SQL and/or indexedDB. Still, it'd be nice to have 
some standard API methods and arguments.


Has this list considered moving towards standards in 'chrome' 
extensions? It seems that there is a lot of low-hanging fruit
that, while not exposed to untrusted scripts, could easily be 
standardized between vendors supporting the Widgets spec.



-Charles

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

[Charles Pritchard]

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 system dialogs is scary/surprising and could be annoying[1].

I'm waiting for the day when a security vulnerability is reported for
a system spellchecker. -- And don't laugh, the open source spell
checkers we've used have some really crummy code w/ a rather poor
track record when it comes to buffers and inputs. Thankfully so far
most attacks against them have been by dictionary vendors instead of
users, but...

[1] we still get bugs from people complaining about while(1)alert("boo");


I'm not laughing: using the 'Help' menu in old Windows (what was that, 
98?) to into explorer.exe was one of my favorite security holes. I don't 
think it's unreasonable to expect that spell checkers would be 
distributed within the browser. But I don't want to add on additional 
burdens to UA designers either. I don't think it's reasonable to play 
for system spell checkers to be exploited; if it's being tossed to the 
OS, then it really is an OS responsibility. If there is an exploit via a 
buffer overflow on a string/unicode pattern, it's quite possible that an 
existing spell checker would fail within the existing scheme.


Regarding while(1) alert("boo") -- I really like how the "Ignore further 
notifications from this page" option evolved to solve that issue. Spell 
checkers have something similar that people are used to: "Ignore all".


With the system dialog: Isn't the point here, to maintain consistency 
with the OS? Using an OS-level spell check dialog would do that.


It's not my favorite solution, but I'd like to find some way to inch 
forward (giving up on taking full steps).

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

[Simon Pieters]

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, lists, tables etc and the other stuff usually  
found

in a rich text editor's context menu.  However, once that is done, the
browser's built-in spelling suggestions are no longer available,  
effectively

losing support for inline spell checking.


"The user agent may also provide access to its default context menu,
if any, with the context menu shown. For example, it could merge the
menu items from the two menus together, or provide the page's context
menu as a submenu of the default menu."

http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#context-menus


It could, but it doesn't. Any browser that tried doing that would likely  
just run into compatibility complaints and have to revert it.


Note that the referenced spec section is about  context menus, a  
feature that to my knowledge is not implemented in browsers yet and not  
used by Web content yet.


--
Simon Pieters
Opera Software

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

[timeless]

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 could be annoying[1].

I'm waiting for the day when a security vulnerability is reported for
a system spellchecker. -- And don't laugh, the open source spell
checkers we've used have some really crummy code w/ a rather poor
track record when it comes to buffers and inputs. Thankfully so far
most attacks against them have been by dictionary vendors instead of
users, but...

[1] we still get bugs from people complaining about while(1)alert("boo");

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

[Markus Ernst]

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
properties for images, lists, tables etc and the other stuff usually
found
in a rich text editor's context menu. However, once that is done, the
browser's built-in spelling suggestions are no longer available,
effectively
losing support for inline spell checking.


"The user agent may also provide access to its default context menu,
if any, with the context menu shown. For example, it could merge the
menu items from the two menus together, or provide the page's context
menu as a submenu of the default menu."

http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#context-menus


It could, but it doesn't. Any browser that tried doing that would likely
just run into compatibility complaints and have to revert it.

More importantly, there's no way to instruct or even suggest that the
browser should which leaves users without functioning spell checking and
rich text authors with no way to meet the demands of users.


This looks like a context menu problem to me, not a spell-checking problem.

There are more occasions where an overridden context menu in 
script-driven parts of a webpage is annoying, e.g. it is impossible to 
use "print preview" or "back" on a google map. So, solving the 
context-menu issue might be a boost for a browser vendor.

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

[Benjamin Hawkes-Lewis]

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 that
>> page.
> Limited, meaning not particular to a user's dictionary.

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 use
dictionary profiles to guess at the user's system (potentially down to
operating system and version).

Also your proposed limitation might well require user agents on some
platforms to implement their own dictionary service as opposed to
using platform dictionary services.

For example, say you were building a user agent for OS X. AFAICT you
can't exclude the user's dictionary when querying the system
spellchecking API:

http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSSpellChecker_Class/Reference/Reference.html#//apple_ref/doc/uid/2378

It would also make for a confusing user experience where the same
spellchecking UI yields different results in some web applications for
no obvious reason.

If you don't need the user's dictionary or the same spellchecking UI,
you could disable spellchecking with the "spellcheck" attribute and
roll your own over XHR/web sockets.

http://www.w3.org/TR/html5/editing.html#spelling-and-grammar-checking

--
Benjamin Hawkes-Lewis

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

[Charles Pritchard]

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 understand that a 'custom' system dictionary could expose
>> private data ... Just as 'suggestions' on form elements do.
> 
> Suggestions on form elements can’t be accessed by script on the page.
> They only expose information that the user selects.
Yes, that's what I meant.

> 
>> 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 that
> page.
Limited, meaning not particular to a user's dictionary.

> 
> The assertion is that it is a violation of the user’s privacy for a web
> page to know whether a word is in the user’s dictionary or not.  An API
> to perform spelling checks and return their results would expose this
> information.  As currently handled, spelling checks are done purely at
> the UI level, and information about the dictionary is not exposed to
> script.

Yes, and it's a valid assertion. That's why I'm looking for methods to work 
with that taken into account.

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

[Cameron McCormack]

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 form elements can’t be accessed by script on the page.
They only expose information that the user selects.

> 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 that
page.

The assertion is that it is a violation of the user’s privacy for a web
page to know whether a word is in the user’s dictionary or not.  An API
to perform spelling checks and return their results would expose this
information.  As currently handled, spelling checks are done purely at
the UI level, and information about the dictionary is not exposed to
script.

-- 
Cameron McCormack ≝ http://mcc.id.au/

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

[Charles Pritchard]

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 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 
> appear to have chosen to ignore me.
> 
> --Oliver
> 
> On Nov 27, 2010, at 12:19 PM, Charles Pritchard wrote:
> 
>> 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 contentEditable section, along the lines of 
>> getSpellcheckRanges() would allow for content editors,
>> to stylize and provide further UI controls around spell checking. Such an 
>> API could be used to warn the user that
>> they have possibly misspelled text, in a similar way to how word processors 
>> convey the information.
>> 
>> It may not be feasible at the moment, but it could be worth some discussion. 
>> A Range list seems appropriate, though
>> it would need something along the lines of getSuggestedSpelling() on each 
>> range.
>> 
>> 
>> -Charles
>> 
> 

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

[Charles Pritchard]

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 dictionary could expose private data ... Just 
as 'suggestions' on form elements do.

What breach is enabled by using a limited spell check?

dataTransfer has done a lot to demonstrate unobtrusive ways of transferring 
limited data, and gives me hope that there may be more interop in the future.




On Nov 28, 2010, at 6:56 PM, Oliver Hunt  wrote:

> 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 
> appear to have chosen to ignore me.
> 
> --Oliver
> 
> On Nov 27, 2010, at 12:19 PM, Charles Pritchard wrote:
> 
>> 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 contentEditable section, along the lines of 
>> getSpellcheckRanges() would allow for content editors,
>> to stylize and provide further UI controls around spell checking. Such an 
>> API could be used to warn the user that
>> they have possibly misspelled text, in a similar way to how word processors 
>> convey the information.
>> 
>> It may not be feasible at the moment, but it could be worth some discussion. 
>> A Range list seems appropriate, though
>> it would need something along the lines of getSuggestedSpelling() on each 
>> range.
>> 
>> 
>> -Charles
>> 
> 

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

[Oliver Hunt]

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 appear to have chosen 
to ignore me.

--Oliver

On Nov 27, 2010, at 12:19 PM, Charles Pritchard wrote:

> 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 contentEditable section, along the lines of 
> getSpellcheckRanges() would allow for content editors,
> to stylize and provide further UI controls around spell checking. Such an API 
> could be used to warn the user that
> they have possibly misspelled text, in a similar way to how word processors 
> convey the information.
> 
> It may not be feasible at the moment, but it could be worth some discussion. 
> A Range list seems appropriate, though
> it would need something along the lines of getSuggestedSpelling() on each 
> range.
> 
> 
> -Charles
> 

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

[Benjamin Hawkes-Lewis]

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

[Adrian Sutton]

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
>> in a rich text editor's context menu.  However, once that is done, the
>> browser's built-in spelling suggestions are no longer available, effectively
>> losing support for inline spell checking.
> 
> "The user agent may also provide access to its default context menu,
> if any, with the context menu shown. For example, it could merge the
> menu items from the two menus together, or provide the page's context
> menu as a submenu of the default menu."
> 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#context-menus

It could, but it doesn't. Any browser that tried doing that would likely just 
run into compatibility complaints and have to revert it.

More importantly, there's no way to instruct or even suggest that the browser 
should which leaves users without functioning spell checking and rich text 
authors with no way to meet the demands of users.

Regards,

Adrian Sutton.
__
Adrian Sutton, CTO
UK: +44 1 628 353 032  US: +1 (650) 292 9659 x717
Ephox http://www.ephox.com/
Ephox Blogs http://people.ephox.com/, Personal Blog http://www.symphonious.net/

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

[Benjamin Hawkes-Lewis]

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 done, the
> browser's built-in spelling suggestions are no longer available, effectively
> losing support for inline spell checking.

"The user agent may also provide access to its default context menu,
if any, with the context menu shown. For example, it could merge the
menu items from the two menus together, or provide the page's context
menu as a submenu of the default menu."

http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#context-menus

--
Benjamin Hawkes-Lewis

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

[Adrian Sutton]

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: 
> 

This isn't just a styling function though.  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 done, the browser's built-in 
spelling suggestions are no longer available, effectively losing support for 
inline spell checking.

I work for a company that sells both Java applet and pure-JavaScript editor 
technologies and the support for inline spell checking (without giving up a 
customized context menu) is one of the most common and most important factors 
driving people to choose the Java applet over pure-JavaScript.

Regards,

Adrian Sutton.
__
Adrian Sutton, CTO
UK: +44 1 628 353 032  US: +1 (650) 292 9659 x717
Ephox http://www.ephox.com/
Ephox Blogs http://people.ephox.com/, Personal Blog http://www.symphonious.net/

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

[Christoph Päper]

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

[timeless]

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
platforms I use, spell checkers are system global (e.g. OS X), not
browser local.

> As
> far as I was aware, password fields are very special, and don't do a lot of
> things that other fields do, so it wouldn't be difficult for it to not do
> something else would it?!

Input Methods are also system global. On mobile platforms you often
have a Terminal application which doesn't hint to the IME when a
remote session is masking passwords. Thus the IME has no way of
knowing that what you're typing is a password.

Have you ever tried to write a shell which was fully aware of what a
(potentially localized) password prompt looked like? It's pretty much
impossible. When presented with complaints that "dictionaries are
learning passwords", UI designers take the "oh no!, let's turn off the
dictionary for app A!" approach, this doesn't help app B nor does it
help the user (where most of the learned "words" are in fact used
frequently and worth not having to type out).

On old mobile platforms the closest things to a spell checker is the
completion dictionary (new "words" are managed automatically by the
IME). - This includes Maemo 5 which was released in 2009, not a long
time ago.

Given past behaviors of IME/dictionaries, I think it isn't
unreasonable to expect similar behavior in future dictionaries on
future platforms.

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

[Ashley Sheridan]

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.
> 
> Some devices have a tendency to learn passwords as typed words, other
> private terms get added to known words. If a web page has the ability
> to talk to the spell checker, it could send it a stream of things
> which aren't in a standard dictionary to determine if they are in the
> user's custom dictionary.


But why would a password field ever be tied to a contentEditable
section? As far as I was aware, password fields are very special, and
don't do a lot of things that other fields do, so it wouldn't be
difficult for it to not do something else would it?!

Thanks,
Ash
http://www.ashleysheridan.co.uk

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

[timeless]

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, other
private terms get added to known words. If a web page has the ability
to talk to the spell checker, it could send it a stream of things
which aren't in a standard dictionary to determine if they are in the
user's custom dictionary.

[whatwg] Exposing spelling/grammar suggestions in contentEditable

[Charles Pritchard]

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 contentEditable section, along the lines of 
getSpellcheckRanges() would allow for content editors,
to stylize and provide further UI controls around spell checking. Such 
an API could be used to warn the user that
they have possibly misspelled text, in a similar way to how word 
processors convey the information.


It may not be feasible at the moment, but it could be worth some 
discussion. A Range list seems appropriate, though
it would need something along the lines of getSuggestedSpelling() on 
each range.



-Charles