W3C home > Mailing lists > Public > public-canvas-api@w3.org > October to December 2010

Re: html5 editor responds to Canvas accessibility related bugs

From: Charles Pritchard <chuck@jumis.com>
Date: Sun, 03 Oct 2010 11:30:19 -0700
Message-ID: <4CA8CBBB.3030408@jumis.com>
To: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
CC: Oliver Hunt <oliver@apple.com>, Ian Hickson <ian@hixie.ch>, public-canvas-api@w3.org, public-canvas-api-request@w3.org
  On 10/3/2010 10:37 AM, Benjamin Hawkes-Lewis wrote:
> Your other argument is that text editors should support "all" of the worlds languages. Nobody has that expectation.
> [snip]
This was made in the context of individual programmers serving their 
clients needs; it was not made in the context of browser-vendors 
distributing web browsers as part of their w3c obligations.
>> 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.
> The HTML WG is chartered "to ensure HTML provides effective support for internationalization" (same as it's chartered "to ensure that the deliverables will satisfy accessibility requirements").
>
> http://www.w3.org/2007/03/HTML-WG-charter.html
>
> The mission of the W3C's internationalization activity is "to ensure that W3C's formats and protocols are usable worldwide in all languages and in all writing systems".
>
> http://www.w3.org/International/about
>
> Real-world text is not hermetically sealed from other languages. Software supporting natural language entry should allow free text input in all languages as free text may include the odd word, /bon mot/, or quotation from another language.
"natural language entry" is spoken and/or signed. Real-world text is not 
constrained to the glyphs on a keyboard, nor the implementation status 
of the language within Windows, OS X, nor their content areas. The W3C 
has put forward all best efforts to ensure the formats and protocols are 
usable, and effective. Between IPA fonts, InkML, <audio> and <video>, 
and iso639-3 tagging, linguistics is well served by the w3c.

I believe the w3c is operating well in that respect.

Individual programmers are not in language neutral environments. And I 
hear Oliver stating his concerns about programmers misguided attempts at 
language entry support, and how those attempts circumvent the work that 
he, and many others, put into their browsers. I don't feel that his 
stated recourse, of restricting individuals from working outside of the 
confines of browser vendor's language entry utilities, is an acceptable 
solution. I don't think we need a solution; that kind of management is 
best left to individual corporations.

>> 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?
> Why do you think SVG contentEditable would take longer to design and implement than the necessary accessibility and internationalization features for "canvas"?
Wherein, in this context, have I claimed a set of necessary features? 
We're still trying to explore that area. That exploration has been 
halted, in relation to canvas, by strong statements from Oliver and Ian.

As for SVG contentEditable, I think it'll be awhile, because it's been 
awhile. In the here-and-now, SVG support in browsers is improving, and 
will continue to. But, in the hear and now, I can do a lot more with 
"canvas"-based interactive graphics than I can do with SVG.


>> Such attitude is in deep conflict with the open and evolving nature of the web
> Designing text editing features that bar authors producing non-English content from participation would also be in conflict with the open nature of the web, would it not?
>
What misguided statement did I put forward to suggest that authors 
should be barred from non-English content?

I've been saying quite the opposite: that programmers should not be 
restricted by browser vendors, into how text editing may work in their 
web applications. That doesn't mean that we need to slow-down current 
APIs, make new half-assed APIs, or otherwise adjust resources.

Most accessibility proposals can more quickly and easily be prototyped 
in a canvas-based text editor than in a browser code base. I can hit 
reload faster in my web browser, using a JS prototype, faster than 
Oliver can compile WebCore and reload his browser.

I'd hope that, instead of seeing our goals in conflict, we might move 
forward together, with our varying strengths, motivations and resources.

At this point, I have a hard time seeing Ian and Oliver's stance as 
anything more than stating: you must use the widgets provided, nothing more.
As a corollary: canvas 2d api and ecmascript are unsupportable, Quartz, 
Cairo, Skia, and various other apis, programmed via c++ , is the only 
way to implement text entry.

I understand Ian's hesitation, and warnings on the canvas spec about 
using canvas unnecessarily. They are appreciated. They don't apply to 
all use cases.

-Charles
Received on Sunday, 3 October 2010 18:37:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 3 October 2010 18:37:17 GMT