W3C home > Mailing lists > Public > public-canvas-api@w3.org > July to September 2011

Re: hit testing and retained graphics (resending)

From: James Robinson <jamesr@google.com>
Date: Fri, 8 Jul 2011 13:32:09 -0700
Message-ID: <CAD73mdK992=AyQ2B-4xd7qnUQjMHDXgwHk9EuvecOZa1=DKx+w@mail.gmail.com>
To: Richard Schwerdtfeger <schwer@us.ibm.com>
Cc: Doug Schepers <schepers@w3.org>, Judy Brewer <jbrewer@w3.org>, "public-canvas-api@w3.org" <public-canvas-api@w3.org>, public-html-request@w3.org
On Fri, Jul 8, 2011 at 1:25 PM, Richard Schwerdtfeger <schwer@us.ibm.com>wrote:

> Rich Schwerdtfeger
> CTO Accessibility Software Group
> public-html-request@w3.org wrote on 07/08/2011 01:18:21 PM:
> > From: Doug Schepers <schepers@w3.org>
> > To: Richard Schwerdtfeger/Austin/IBM@IBMUS
> > Cc: Judy Brewer <jbrewer@w3.org>, "public-canvas-api@w3.org"
> > <public-canvas-api@w3.org>
> > Date: 07/08/2011 01:19 PM
> > Subject: Re: hit testing and retained graphics (resending)
> > Sent by: public-html-request@w3.org
> >
> > Hi, Rich-
> >
> > A few points in reaction to your recent emails:
> >
> > 1) It is inappropriate for you to question people's motives as part of
> > your argument; you did it to Tab when he was trying to solidify
> > use-cases and requirements, you've done it with others, and now you've
> > done it with me. This is classically called an "ad hominem" fallacy...
> > it is inappropriate not because it's rude (though it is), nor because it
> > decreases the technical level of dialog (though it does), nor because it
> > tends to deafen you to the points the other is making (though it does),
> > but because it does not refute or even address the technical merits of
> > the other's position.
> >
> Doug, I merely stated that this was an observation. ... That was how it was
> coming across to me in email. I did not know if you knew that was how you
> were coming across. Nothing more than that. Email stinks as a communication
> vehicle. I think people read more into emails than they were intended.
> > 2) I have no concern about people using SVG. They will or will not
> > based on the specific use case. Perhaps a few years ago, I would have
> > been more concerned, but now SVG is supported in all major browsers, and
> > it is very unlikely to be removed; we have all the major browser vendors
> > and key authoring tool vendors participating in the SVG WG, and we are
> > working closely and productively with the CSS WG. SVG works with HTML5
> > in all browsers, and we will continue to make improvements in that
> > integration; we also have specific plans for improvements in SVG's
> > accessibility, including (but not limited to) extensions of ARIA. SVG
> > is doing just fine.
> >
> That is great. I was simply asking why you did not push for it to be part
> of the HTML 5 spec. I did not state that it would not work with HTML 5.
> > 3) You are apparently confused about certain aspects of SVG, and have
> > clearly not understood my proposal, nor understood browser vendors'
> > responses to certain aspects of it. I did not suggest, as you seem to
> > think, replacing the whole set of "subtree/shadowtree" accessibility
> > hooks, but rather suggested how SVG could be used with that subtree as
> > the locative aspect of certain visual features, rather than inventing a
> > whole new retained-mode API or markup, which browser vendors have
> > already rejected.
> >
> I understood that completely. As I said the implementation would benefit
> from using the canvas fallback content subtree.
> > 4) I realize that you are trying to help accessibility, but the solution
> > you are advocating is an ungainly hack that is unlikely to grow to meet
> > the real needs of authors and users that will arise as they start to use
> > it in depth. You keep saying that you are "roughly 1 feature away from
> > fixing canvas accessibility"... and you always will be, because you are
> > patching the obvious flaws, not the ones that will arise like zombie
> > whack-a-moles.
> >
> Why is simple hit testing a hack. I keep hearing that people don't want
> full retained mode graphics. I am trying to provide hit testing capability
> and accessibility without a full grown retained graphics model that is
> already in SVG.
> > 5) I've taken time out of my extremely busy schedule to try to help find
> > a third path here, between your retained-mode canvas extensions and
> > browser vendors' proposal that authors use SVG for those cases instead,
> > because I care about graphics accessibility. I think that a shared
> > Canvas-SVG 2D graphics API is desirable for general use, and also
> > happens to address the specific use cases you seem to have expressed for
> > the problem at hand [1]; the SVG WG will be working on this SVG-Canvas
> > integration at our next F2F this month in any case. You don't seem to
> > agree currently that this is a good solution, citing that certain parts
> > of it need to be defined and implemented (which we agree on), but seem
> > to overlook this same flaw in your own proposal (along with the added
> > disadvantage that browser vendors have said they will not implement your
> > proposal). But I have neither time nor inclination to quibble with you.
> > If you change your mind, and want to develop the Canvas-SVG idea
> > further, I'll be happy to help. If not, I wish you luck in finding
> > another solution that meets your use cases and is acceptable to
> > implementers.
> >
> No. I did not say that I did not agree with the solution. In fact, there is
> a lot of merit in addressing the two solutions together as it would allow us
> to work on SVG accessibility as well as canvas at the same time. If SVG
> could use a similar shadow DOM with accessibility support based on HTML 5
> that would be huge!
> I simply stated that I have not heard browser vendors weigh in on the fact
> that they supported it (somewhere in my last 2 notes). Please don't take
> this personally. This was my quote: "Doug, I think the problem is that the
> browser manufacturers have also not supported the integration of SVG into
> canvas."
> Have you heard from Microsoft, Apple, or Google that they would support
> this approach? If so, I am all in. I mean if you are going to put in all
> this work on canvas-svg integration I would try to get some buy in on the
> approach to start. This is why I have avoided prototyping hit testing in
> canvas. Frankly, the hit testing is not terribly hard to do but like you I
> have a lot of demands on my time.

To be perfectly frank, speaking only for myself and not for other people at
Google or in the Chromium project, I've been reluctant to chime in on these
threads because it seems that everyone who does gets flamed out within a few
messages.  If this mailing list was not so toxic I suspect there would be a
broader, more productive discussion.  That said, I'm confident that Doug's
proposal will be given due consideration by the proper people at the proper

- James

> I also have a lot of questions. I don't want to throw away all the
> accessibility work we have done so far, which is extensive, on canvas. For
> example, what do we do FocusRing? Is there a way we can reuse it in SVG in a
> common API. How would we address keyboard support. SVG has great keyboard
> support but it is different from HTML 5. ... these types of questions.
> If you don't get buy in from the browser manufacturers the end result will
> be as fruitful as our current efforts to add hit testing on canvas.
> I know people like to do a ton of email like this but frankly I would
> prefer to just pick up the phone or have a face to face.
> > [1] http://www.w3.org/WAI/PF/HTML/wiki/Canvas_Accessibility_Use_Cases
> >
> > Regards-
> > -Doug
> >
Received on Friday, 8 July 2011 20:32:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:10:32 UTC