[whatwg] Exposing spelling/grammar suggestions in contentEditable
chuck at jumis.com
Fri Dec 3 14:00:39 PST 2010
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<table> 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
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
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
Existing IMEs for pen input are lacking, current contentEditable
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
>> 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
> 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.
More information about the whatwg