W3C home > Mailing lists > Public > public-canvas-api@w3.org > January to March 2011

Re: Looking at an IME Proposal

From: Paul Bakaus <pbakaus@zynga.com>
Date: Mon, 17 Jan 2011 01:58:06 -0800
To: Charles Pritchard <chuck@jumis.com>, Richard Schwerdtfeger <schwer@us.ibm.com>
CC: Frank Olivier <Frank.Olivier@microsoft.com>, Cynthia Shelly <cyns@microsoft.com>, "david.bolter@gmail.com" <david.bolter@gmail.com>, "janina@rednote.net" <janina@rednote.net>, "oedipus@hicom.net" <oedipus@hicom.net>, "public-canvas-api@w3.org" <public-canvas-api@w3.org>, "public-html-a11y@w3.org" <public-html-a11y@w3.org>, Shawn Warren <swarren@aisquared.com>, Tim Lalor <tlalor@aisquared.com>
Message-ID: <C959C182.1DD3%pbakaus@zynga.com>

Am 14.01.11 22:36 schrieb "Charles Pritchard" unter <chuck@jumis.com>:

>An early post from Hironori Bono:
>Ian showing interest, but also defensiveness:
>The chilling effect:
>This chilling effect is not based on actual costs to browser vendors.
>Very simple fixes to the existing spec are neglected:
>Neglected is not the right word: they are discouraged.
>WCAG requires that content be labeled so as to be "Programmatically
>Determined". Serialization is a valid use case.
>So is making canvas based UI accessible:
>"Guideline 8. Ensure direct accessibility of embedded user interfaces."
>Vendors should be promoting APIs to share information about the GUI, as
>stated in WAI-USERAGENT:
>Guideline 6. Implement interoperable application programming interfaces
>"Programmatic access" is very much encouraged.
>Currently, programmatic access to input devices, and to form elements,
>specifically <input type="text"> <textarea> and <div contentEditable> is
>severely restricted.
>That's something that additional work in the IME realm can provide.
>I can not, at current, scroll the text inside of <input type="text">,
>accurately measure
>the width of that text, nor determine where the cursor is in that text
>I've worked very hard on whatwg and w3c lists to address real,
>identifiable usability to concerns,
>and encountered incredible push-back under the guise of questioning "Use
>Case" validity.
>As I've stated, many times, I no longer put forward Canvas as a use
>case, in my proposals.
>Fortunately, I don't need to: The API deficiencies we're exploring are
>deficiencies in other web technologies.
>The current debate is as to whether web programmers may develop their
>own IME, and whether
>it's a valid use of the scripting environment. I feel that it's valid,
>some browser vendors do not.

Just a quick note, as I think it might be relevant: I can prove this is a
valid use case, as I've actually wrote japanese IME's in JavaScript before
(difficult, indeed). It was for the JS based learning applications of the
learning startup smart.fm, where people might for instance study japanese,
but don't know or can't install an IME.

Let me know if there's interest in the actual code to find out about
patterns and deficiencies and I'll try to see what I can do publish it. I
did have all kinds of trouble with measuring text etc.

Received on Monday, 17 January 2011 09:58:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:31:52 UTC