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