Re: html5 editor responds to Canvas accessibility related bugs

  On 9/29/2010 3:53 PM, Oliver Hunt wrote:
> Charles sent me a email directly, and i'm unsure if he was okay with 
> me forwarding it, so I am not, but as background for
Thought I might get a direct reply as well. I do appreciate the content 
you've put down here.
> This isn't simply a question of layout, it's a question of text 
> _entry_, specifically the mechanisms of how this works, the most 
> simple are dead characters but the range to complex selective and 
> context aware input methods such as those used for japanese, 
> traditional and simplified chinese, etc.  Text entry for even the most 
> simple of scripts does not necessarily correlate the keyCode or 
> charCode to the actual character that is expected to be shown.
Yes, input methods are complex.

How is that a reason for discouraging programmers from coding text entry?

> For example the default input managers for many of the latin scripts 
> (english, french) on Mac OS makes use of dead characters for accents 
> and alternate character selection, and windows lets you install 
> different input managers (or installs by default if you're in the 
> appropriate locale) for similar features, although the input mechanism 
> and ui is substantially different.
I'd imagine there are use cases, especially in Web Apps, where a unified 
UI is preferred over a OS-based UI.
This is typically been the case in gaming, and intranet applications.

> A very simple example of how much people overlook is the character 'ß'
... And ? Often, people do not need to cater to every locale.

There are many use cases in the U.S., where accessibility is more 
important than
supporting pan-European languages.
> This also ignores the user visible UI, which agains differs from OS to 
> OS, language to language, input method to input method.  I'll now try 
> to illustrate the range and complexity of text entry using a pile of 
> screenshots.
I'm thankful for your work gathering illustrations.

Google provides transliteration services; as well as translation 
services. It seems to me, that an IME API might be worth pursuing for 
this particular use-case. Though the OS (and let's be real, OS X is by 
far the leader) may come with transliteration and translation services, 
server-assisted translation still has something to offer.

If we had a standard API for this, Google Translation and other 
translation services might support that API. Wouldn't that be swell?
> This a small sample of just a few of the different IMEs that come by 
> default with MacOS, there are multiple 3rd party IMEs for many 
> languages, some of which are very popular, many with completely 
> different behaviours, some with their own distinct UIs, etc.  Again 
> this is only MacOS, Windows has its own IMEs, and has many third 
> parties IMEs there as well, and they have different UIs and behaviour 
> as well, and Linux has its own as well.
People develop IMEs in the browser as well. Sometimes they try to do it 
with <canvas>. It's one of the strong use cases for supporting canvas 
based "text editing". Though I think interactive glyphs is a more open 
concept. Web Fonts are not necessarily involved.
> Because of these huge differences between the IME models from one OS 
> to another it is not possible to produce a complete and sane API that 
> would allow JS to interact with these correctly, and even if it were, 
> a huge amount of work is needed to get correct behaviour as you are 
> required to communicate a large amount of information with the IME, 
> and the IMEs require a very rich interface in order to correctly 
> control what the user can see.  After all of that there's also the 
> potential for information leakage and other security issues (phishing, 
> etc) that would make me very reticent about allowing JS to control 
> data being fed to the IMEs.
Agreed.

Spell check, translation and transliteration APIs, if pursued, should be 
very cautious with security.

> My hope is that by making the complexity of text input visible to the 
> people reading this thread you can understand why I am opposed to APIs 
> that attempt to make it possible to create editors using canvas -- it 
> is simply not possible to create an API that allows someone to create 
> a fully fledged editor, and any attempt is simply going to result in a 
> half-assed API that only works "mostly" for people of the english (or 
> similar scripted) speaking/writing world.
Your concept of a fully fledged editor is unique to your situation, and 
your corporation.
To some people, Bespin is a fully fledged editor. To others, the f*ck 
editor is fully fledged.

I can't simply take your word for it, that web coders are unable to turn 
a fledgling editor
into something full and robust; nobody on this list is asking for a 
half-assed API.

The issue here, is that Ian and you are verbalizing your opposition 
toward  any API supporting "editors using canvas".
Your argument seems to be that text editing is complex, too complex for 
others to implement.
Your other argument is that text editors should support "all" of the 
worlds languages. Nobody has that expectation.

Programmers get their specs from their clients. If their client only 
wants to support English, or some
subset of languages, I don't see an issue.

> Rather than saying there are legal obligations that require you to 
> create an accessible interface for a editor written in canvas, you 
> should be asking what it is that has resulted in the need to roll your 
> own editor in the first place.  Then request appropriate features in 
> the browsers directly, as the browsers already correctly manage user 
> input, are able to interact with them safely, and ensure that any IME 
> UI are correct.
I'm asking for what is needed to create additional IMEs.

If I wanted IME support, I'd use <input> or <textarea>, set opacity to 
zero,
or otherwise stylize that part of text entry.

Tell me, how do I allow someone to edit text which is along a path?
Do I wait a few years for SVG contentEditable?

These use case questions are irrelevant when taken in context: You and 
Ian have both stated that,
regardless of use-case, regardless of resources, programmers should not 
create an editor which presumably
connects keyboard entry to a canvas screen, producing glyphs.

There's no reason for providing use cases, as your stance on this is 
inflexible.

Here's another use case: character recognition from pen input.
Another: re-using the strokes from pen input, instead of a 'font'.
Another: maintaining a strictly <canvas> based UI.
Another: stylizing glyphs with non-standard markers.
Another: non-standard languages and scripts.
Another: supporting languages or glyphs not available on the computer or 
true type.
Another: supporting pictographic or other image-based input systems.
Another: supporting text entry within a webgl context.

These are far and distinct from your use cases as a major browser vendor.
I'm passionate about this issue, and quite upset, because you are both 
telling me that
text entry should be limited to controls supported by major operating 
systems.

I'm pleased with the recent change of tone in this thread, as I found it 
to be quite disrespectful
in its earlier direction.

I do appreciate both of your input, and your continued work. I certainly 
look forward to to seeing
some of the ideas on this thread evolve: those from Ian about 
accessibility specs,
and those from you about a limited set of IME APIs.

I don't see how those arguments are logically relevant to the conclusion 
that ECMAScript coders, using
the canvas API, should be fully discouraged [from you two, sources of 
authority] from implementing
any sort of text editing device.

Such attitude is in deep conflict with the open and evolving nature of 
the web,
and I can not, for the life of me, understand from this thread, where 
that restrictive attitude
is truly rooted with you nor with Ian.


-Charles