- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 6 Jul 2011 18:26:07 -0700
- To: Charles Pritchard <chuck@jumis.com>
- Cc: Charles McCathieNevile <chaals@opera.com>, "E.J. Zufelt" <everett@zufelt.ca>, Paul Bakaus <pbakaus@zynga.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 Wed, Jul 6, 2011 at 6:16 PM, Charles Pritchard <chuck@jumis.com> wrote: > What do you mean by "run the web"? > > My comment was a reflection on the abundance of canvas implementations and how relative to SVG, canvas was quickly implemented. You asked me why I thought it likely that vendors would pick up -one- additional method in the specs. I answered; relative to more expensive standards such as SVG, which have taken a lot more time to implement. SVG is already supported by every major browser implementor. That said, implementations are lower priority than authors or users when weighing features. In general, users are most important, authors are below users, and implementations are below authors. (Below implementations are spec authors and theoretical purity.) > We are still discussing a simple and straightforward continuation of the focus ring / shadow dom effort. The shadow Dom is already in the specs-- this is a minimal addition and neatly fits in with other semantics from the Accessibility tree, the canvas subdom and DOM Core. The focus ring API was specifically designed to offer some benefits to the author, and to make it reasonably obvious when they're doing it right. This fulfills several of the criteria I offered up previously concerning what a good accessibility solution would look like. (Note that it didn't *have* to do so; in fact, omitting those qualities would have made a simpler and more understandable API. But that simpler API wouldn't be used as much, and thus accessibility would be helped less.) So far, the same is not true of binding paths to elements and somehow figuring out z-order. (Just creating paths is high-value for several reasons unconnected to accessibility, but the simplest solution to those problems does not help accessibility.) > I understand you're an idealist, but you're blocking the way forward. Sigh. I'm trying to make sure you're actually solving real problems. That's all I've been doing this entire time. This is a fundamentally realistic stance that's proven effective in the past. ~TJ
Received on Thursday, 7 July 2011 01:26:59 UTC