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