Re: hit testing and retained graphics

Rich Schwerdtfeger
CTO Accessibility Software Group

public-canvas-api-request@w3.org wrote on 07/06/2011 04:25:02 PM:

> From: "Tab Atkins Jr." <jackalmage@gmail.com>
> To: Charles Pritchard <chuck@jumis.com>
> Cc: Charles McCathieNevile <chaals@opera.com>, Henri Sivonen
> <hsivonen@iki.fi>, "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>
> Date: 07/06/2011 04:25 PM
> Subject: Re: hit testing and retained graphics
> Sent by: public-canvas-api-request@w3.org
>
> On Sat, Jul 2, 2011 at 9:01 AM, Charles Pritchard <chuck@jumis.com>
wrote:
> > On 7/1/2011 12:15 PM, Tab Atkins Jr. wrote:
> >>
> >> Honestly, attempting to reimplement HTML in<canvas>  sounds like a
> >> great way to give your competitors a free head-start against you.
> >
> > This is very you/your-industry centric.
> >
> > There are several implementations for HTML rendering for output to PDF
> > and other document formats. Companies have built products based on it.
> >
> > You seem to misunderstand the diversity of a free market.
> >
> > Consider that a company might start-up, with the intention of creating
> > another HTML to PDF rendering utility; or a rendering utility for some
other
> > format.
> >
> > By implementing in ECMAScript, they may indeed have a head-start
against
> > other companies implementing in C++;  though ecmascripten and NaCl
> > are great projects, I'd see greater success sticking to ECMAScript and
> > Canvas
> > to implement with.
>
> I'm not sure how writing an HTML-to-PDF converter is relevant here.
> PDFs are useful outside the web.  We're talking about writing webapps
> in the browser that reimplement the browser.  If you want to use PDF
> in an analogy, it's like designing a webpage by first writing HTML,
> then converting to PDF, then hosting those on your site.
>
>
> >> (Imo, we should continue to make it difficult to do full-featured text
> >> and UI in canvas, so that it stays painful.  Then we can make it less
> >> painful to do things the right way, and natural incentives will help
> >> people make the right choice.)
> >
> > Why would you say that out loud Tab? The world is hard enough as it is.
> > It pains me to see this kind of thinking applied to such important
> > decisions.
> >
> > I should not have to defend free enterprise to developers on a web
> > standards mailing list.
> [continued in the following reply]
> > IMO, if your strategy includes actively or passively creating or
maintaining
> > "painful" situations for developers, you are doing it wrong.
> >
> > If you have something to back that stance up, share it here. I'm not
for
> > DRM, I'm not for obfuscation,
> > nor am I for over-specification. But -- if you want to put those
forward as
> > an argument, I will keep
> > an open mind, as I do understand there are a business needs for each.
>
> I... I don't know how you achieved such a confusion over my goals or
> my proposed solutions.
>
> There are right ways and wrong ways to do things.  Ideally, the right
> way is easy, and the wrong way is painful.  That way, natural
> incentives will encourage people to do things the right way.  We don't
> need to force *everyone* to do things the right way - it may very well
> be the case that, on occasion, the "wrong" way is actually right for
> an individual situation - but as long as most people do things right,
> we're okay.
>
> In this specific topic, the right way to get bounds information for
> objects, associate drawn images with captions, keep text around so it
> can be read later by a machine, etc. is to use a retained-mode API.
> The wrong way is to use an immediate-mode one.
>
> We can choose to patch the latter into the former.  It has a good
> chance of turning out badly, because the basic assumptions underlying
> the two approaches are somewhat incompatible.  Or, we can promote
> existing examples of the former (like SVG), find out what problems
> they have that make them difficult to use, and fix them.  Or, we can
> come up with new retained-mode solutions that are designed up-front to
> solve the problems we know of and be easy to use.
>
> I'm on the side of one of the latter solutions, but only because I
> think it has a better chance of solving accessibility problems
> "automatically".  I am *strongly opposed* to any solution that is
> completely optional, as that will leave the large majority of
> applications using the relevant technology less accessible.
>
Tab, I would support a new retained-mode solution that would allow for
getting accessibility automatically. Were you thinking of tossing the
existing 2D canvas api for a new one or writing a modification to it that
operated off a retain mode model?
Do you think this would garner support from the other browser vendors?

A way to force retained mode and hit testing would be to basically say that
in order to state that canvas is an element such that unless an author
creates a context, binds it to a separate fallback DOM object, applies a
bounding path, and applies a Z order that pointing events would not be
processed by the user agent on the canvas element. That would certainly
force the issue. I suspect you could keep most of the API you have.

Today, you get a single context directly from the canvas element for
browsers that support canvas.

On Window systems you have to create a new device context for each retained
mode object.

> ~TJ
>