RE: hit testing and retained graphics

-----Original Message-----
From: Tab Atkins Jr. [mailto:jackalmage@gmail.com] 
Sent: Thursday, June 30, 2011 10:21 AM
To: Matt May
Cc: Cameron McCormack; public-canvas-api@w3.org; public-html@w3.org; public-html-a11y@w3.org
Subject: Re: hit testing and retained graphics


> It appears you may be slightly confused about your terminology.  You
> just defined a retained-mode API - the fact that those five vectors
> stick around as things you can refer to automatically implies you're
> working in a retained-mode API.

No, I'm really not. I'm pointing out that, if you keep drawing the same vectors over and over in immediate mode, you've basically built a retained-mode model. And that's what's happening in canvas. And that's the problem.

> As I've pointed out in the past, a text field is *far
> more* than just its position and value (or even the fuller set of
> attributes you list).  An accessible text field must also, for
> example, handle IMEs and properly format bidi text.  

...all of which has to be handled in the framework code, which happens before it's drawn to the screen. Which is where we're talking about working in this accessibility API.

> (I'll note that textboxes in Flash are generally horrible.  I dunno if
> there's a *right* way to do textboxes in Flash, but people do them
> wrong *so often*.)

Thanks for your feedback. And yes, there is a right way to do text fields in Flash and Flex: it's by using or subclassing the components that are provided, which happen to have all the accessibility and IME and UX features implemented. The components have been there since Flash MX/Flash Player 6. If you go your own way, as many have, you obviously have all that extra work to do. Which underscores my point: just telling people that such-and-such is the wrong way to do things has virtually no effect in the marketplace, as you can attest.

-
m

Received on Thursday, 30 June 2011 17:38:58 UTC