On Thu, 30 Dec 2010, Nils Dagsson Moskopp wrote:
Ian Hickson i...@hixie.ch 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.
On Sat, Jan 1, 2011 at 7:12 AM, Benjamin Hawkes-Lewis
bhawkesle...@googlemail.com wrote:
On Sat, Jan 1, 2011 at 1:23 AM, Charles Pritchard ch...@jumis.com 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
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 mark. It's simply not implemented by vendors
at the moment. It is covered
by the
On Sat, Jan 1, 2011 at 1:23 AM, Charles Pritchard ch...@jumis.com 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.
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
Ian Hickson i...@hixie.ch 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
On Wed, Dec 29, 2010 at 11:01 PM, Nils Dagsson Moskopp
nils-dagsson-mosk...@dieweltistgarnichtso.net wrote:
Ian Hickson i...@hixie.ch 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
On Fri, Dec 3, 2010 at 10:05 AM, Adrian Sutton adrian.sut...@ephox.com 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
On Thu, Dec 2, 2010 at 9:53 PM, Benjamin Hawkes-Lewis
bhawkesle...@googlemail.com 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
On Fri, Dec 3, 2010 at 12:07 AM, Charles Pritchard ch...@jumis.com 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
On Mon, Nov 29, 2010 at 6:05 PM, Charles Pritchard ch...@jumis.com 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
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
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
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
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
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
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
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
On 12/2/2010 4:16 PM, Jonas Sicking wrote:
On Thu, Dec 2, 2010 at 4:07 PM, Charles Pritchardch...@jumis.com 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
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
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
On Thu, Dec 2, 2010 at 8:30 PM, Charles Pritchard ch...@jumis.com 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
On Thu, Dec 2, 2010 at 3:30 PM, Charles Pritchard ch...@jumis.com wrote:
I can tell you, that blocking the issue does have real usability costs:
I don't know if everyone here actually agrees with that. Why can't
you rely on the browser's built-in spell-checking? What are you
trying to do here?
On 12/2/2010 4:00 PM, Aryeh Gregor wrote:
On Thu, Dec 2, 2010 at 3:30 PM, Charles Pritchardch...@jumis.com wrote:
I can tell you, that blocking the issue does have real usability costs:
I don't know if everyone here actually agrees with that. Why can't
you rely on the browser's built-in
On Thu, Dec 2, 2010 at 4:07 PM, Charles Pritchard ch...@jumis.com wrote:
On 12/2/2010 4:00 PM, Aryeh Gregor wrote:
On Thu, Dec 2, 2010 at 3:30 PM, Charles Pritchardch...@jumis.com wrote:
I can tell you, that blocking the issue does have real usability costs:
I don't know if everyone here
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
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
adrian.sut...@ephox.com mailto:adrian.sut...@ephox.com wrote:
User's expect a rich text editor
to override the browser default context menu to
On Mon, Nov 29, 2010 at 5:57 AM, Charles Pritchard ch...@jumis.com 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
On Sun, 28 Nov 2010 17:27:30 +0100, Adrian Sutton
adrian.sut...@ephox.com wrote:
On 28 Nov 2010, at 15:52, Benjamin Hawkes-Lewis wrote:
On Sun, Nov 28, 2010 at 3:41 PM, Adrian Sutton
adrian.sut...@ephox.com wrote:
User's expect a rich text editor
to override the browser default context
On 11/29/2010 1:49 AM, timeless wrote:
On Mon, Nov 29, 2010 at 5:57 AM, Charles Pritchardch...@jumis.com 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.
On 11/28/2010 11:30 PM, Benjamin Hawkes-Lewis wrote:
On Mon, Nov 29, 2010 at 4:19 AM, Charles Pritchardch...@jumis.com 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
On Sat, Nov 27, 2010 at 10:19 PM, Charles Pritchard ch...@jumis.com 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
On Sun, 2010-11-28 at 11:27 +0200, timeless wrote:
On Sat, Nov 27, 2010 at 10:19 PM, Charles Pritchard ch...@jumis.com 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
On Sun, Nov 28, 2010 at 12:32 PM, Ashley Sheridan
a...@ashleysheridan.co.uk wrote:
But why would a password field ever be tied to a contentEditable section?
I did not say that html:input type=password was the source of
password data that was learned by the spell checker.
I said that a spell
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:
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:
On Sun, Nov 28, 2010 at 3:41 PM, Adrian Sutton 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.
On 28 Nov 2010, at 15:52, Benjamin Hawkes-Lewis wrote:
On Sun, Nov 28, 2010 at 3:41 PM, Adrian Sutton 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
On Sun, Nov 28, 2010 at 4:27 PM, Adrian Sutton adrian.sut...@ephox.com 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
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
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
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 oli...@apple.com wrote:
It _may_ be worth discussing (as I am not all
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
In thread.
On Nov 28, 2010, at 8:03 PM, Cameron McCormack c...@mcc.id.au 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.
On Mon, Nov 29, 2010 at 4:19 AM, Charles Pritchard ch...@jumis.com 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
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
46 matches
Mail list logo
