- From: Charles Pritchard <chuck@jumis.com>
- Date: Tue, 28 Jun 2011 12:11:33 -0700
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- CC: Charles McCathieNevile <chaals@opera.com>, Richard Schwerdtfeger <schwer@us.ibm.com>, Cameron McCormack <cam@mcc.id.au>, Cynthia Shelly <cyns@microsoft.com>, david.bolter@gmail.com, Frank Olivier <Frank.Olivier@microsoft.com>, Mike@w3.org, public-canvas-api@w3.org, public-html@w3.org, public-html-a11y@w3.org
On 6/28/2011 11:58 AM, Tab Atkins Jr. wrote: > On Mon, Jun 27, 2011 at 4:20 AM, Charles McCathieNevile > <chaals@opera.com> wrote: >> On Thu, 23 Jun 2011 22:28:32 +0200, Tab Atkins Jr.<jackalmage@gmail.com> >> wrote: >>> You are attempting to recreate a retained-mode API in an >>> immediate-mode API. Why is "use SVG" not sufficient for this? >> Because people don't - they use canvas instead. If that were not the case, >> the whole effort to specify canvas would be solving a theoretical problem. > That's not a useful answer.<canvas> is used for lots of things, of > which only a subset are better done in a retained-mode API, of which > only a subset are reasonably handled by mapping clicks into a DOM > node. > > I elaborated my objection to this approach in a later email. This > development thrust seems to be happening without any clear use-cases > to address, and with a preference for minimally-invasive edits to the > 2d canvas context. These seem very likely to give a bad result that > doesn't solve anything well. > > I don't think we'll come up with a *good* result until we have clear > use-cases that we can then solve. Please elaborate on what defines a "clear" use-case. As far as I've seen, we've put forward many -clear- use cases. The responses I've seen have been rebuttals, asserting that future versions of XBL2 and SVG2 would be better matches for the use cases. With all sincerity, I'd like to provide "clear use-cases" for your review. At this point, I've put forward Apple's VoiceOver on Mobile Safari and ViewPlus' hands on learning products as use cases for setElementPath with element and z-index attributes. I've put forward serialization semantics (stringify) for the current path data as another means to make development -easier- on web authors and to make it easier to send path data between SVG and Canvas elements. Are those use cases clear? Should I work further on either? I understand you have a strong objection to having the UA dispatch pointer events directly to the shadow dom. Can we treat that as an independent issue, one which also requires clear use cases? -Charles
Received on Tuesday, 28 June 2011 19:12:28 UTC