On 1/10/2011 7:15 AM, Frank Olivier wrote:
> At this point, the IE team does not think that text editing via canvas
> is a problem that we should tackle for HTML5 due to the inherent
> complexities of the problem and limited options to solve this
> correctly. The best solution for HTML5 (via tooling, education, author
> guidance) is to not fake text entry via canvas elements – much better
> native mechanisms for text editing already exist in HTML5.
I've hit this e-mail a couple of times, sorry about that. There's
another bit of information I need to run by you all:
The Canvas Spec, CRC2D, was moved into its own specification, apart from
HTML5, I believe by request of Adobe.
I want to bring that up, in contrast to statements about the relevance
of HTML5 in decision making on canvas accessibility.
HTML-A11Y is a facilitator of the discussion: we've heard other use cases.
I've produced a few libraries supporting a Canvas + JavaScript profile.
They fall within w3c standards, and are independent of HTML5 browsers.
I realize that by-and-large, the process is driven by browser vendors,
and so HTML5 is assumed. That's fine,
but procedurally, I believe that Canvas Rendering Context 2D exists
outside of the HTML5 standard.
In that light, the Caret interface being discussed is warranted, as a
Canvas method.
I understand that caret is widely, commonly (though not exclusively)
used for text editing, and in other cases,
text selection. I've put forward Google Books [scanned documents] as a
use case where text selection and a caret would be quite helpful.
But that use case is about exposing caret control to the scripting
environment, and could just as well apply to "window".
That's why I'm bringing up Canvas Rendering Context as a separate spec
from HTML5;
because in that light, caret control should be exposed through the
Canvas Context object,
regardless of any other places it may be exposed in the DOM.
-Charles