- From: Charles Pritchard <chuck@jumis.com>
- Date: Fri, 01 Jul 2011 11:08:56 -0700
- To: Charles McCathieNevile <chaals@opera.com>
- CC: "E.J. Zufelt" <everett@zufelt.ca>, Paul Bakaus <pbakaus@zynga.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, John Foliot <jfoliot@stanford.edu>, Richard Schwerdtfeger <schwer@us.ibm.com>, Cameron McCormack <cam@mcc.id.au>, Cynthia Shelly <cyns@microsoft.com>, "david.bolter@gmail.com" <david.bolter@gmail.com>, Frank Olivier <Frank.Olivier@microsoft.com>, "Mike@w3.org" <Mike@w3.org>, "public-canvas-api@w3.org" <public-canvas-api@w3.org>, "public-html@w3.org" <public-html@w3.org>, "public-html-a11y@w3.org" <public-html-a11y@w3.org>
On 7/1/2011 7:41 AM, Charles McCathieNevile wrote: > On Thu, 30 Jun 2011 15:52:52 +0200, Paul Bakaus <pbakaus@zynga.com> > wrote: >> Am 29.06.11 15:50 schrieb "E.J. Zufelt" unter <everett@zufelt.ca>: >>> On 2011-06-29, at 9:33 AM, Paul Bakaus wrote: > >>>> …Mostly, today's canvas applications are game demos and drawing apps. >>>> >>> What about tomorrow? >>> >>>> If you are writing your GUI in canvas, you are doing it wrong... > > (Agreed. That doesn't mean it won't happen) Seen this one a few times, it's never made sense to me. All of the browser vendors use the same underlying graphics libraries to power canvas as they do to power their GUI/render trees. It's the -same- code paths. The difference in GUI is that one is written by a vendor, and compiled via C++ (typically), and the other is written by a developer, with JIT compilation from ECMAScript (typically). Even in ECMAScript, the code path still connects to the Render Blocks; it still passes through the CSS processing tree. You can see this when you boot up a11y monitors; the vendors only use the OS provided widgets for the url bar, and some debugging. Other components are rendered by their low-level graphics libraries [the ones that take a path and fill/stroke the path, then composite]. In many cases, it's the url bar that functions best in a11y, and the rest of the components area mixed bag. The same applies, in some sense, to developers and their relationship with vendors. Devs decide that they're going to use their own css styles, and their own menus, instead of leaving it to the default rendering of each browser. In some cases, this means that the developers inadvertently exclude items in when the user has set their OS to high contrast mode. So, there you have the UA vendors treating the OS in a manner similar to developers treating the UA, with similar pitfalls. If you're writing an application -- you're an application developer. I'd never expect to hear someone criticize a desktop application developer for creating their own buttons, and writing their own widget library. Somehow, several developers on this list think that criticism is appropriate for web application developers. I'm with Doug's statement on his proposal: it's a false dichotomy. But gosh, I'm a little frustrated here, when, we have actually measurable code paths, that can be inspected and referenced, we have specs that prove equivalency. And still, we have vendors and other developers saying that one side of the equivalency is "wrong". ARIA semantics and/or the shadow dom provide for technical equivalency with OS-level UI components: <canvas tabindex="0" role="button"></canvas> == <button tabindex="0"></button> == <canvas><button tabindex="0"></button></canvas> Canvas semantics with CSS attributes provide for equivalency with the UA-level elements in the render tree. You're not "doing it wrong", when you are using the very technology that the browser runs on, and using the DOM/HTML semantics that the web users. When you're following the standards, using standard APIs, you're doing application development "right". -Charles
Received on Friday, 1 July 2011 18:09:55 UTC