Re: hit testing and retained graphics

On Thu, Jul 7, 2011 at 7:55 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> If we instead take the examples that I listed in my email and analyze those:
>
> "pie charts"
> It seems to me that simply requiring screen readers to read the DOM
> contained in the canvas goes a long way here. The author can then put
> the same data as is being displayed in the chart in a <table> which is
> read to the user. This isn't really falling into the category of
> "interactive" which you asked about though.

Doing <canvas><table>...</table></canvas> is acceptable, but it's even
better to draw the pie chart in SVG, so you can do things like attach
descriptions to the slices.

This should be doable with the Component Model we've been discussing,
so you have markup like <x-piechart><table>...</table></x-piechart>,
and construct SVG in the shadow DOM.


> "angry birds"
> I honestly have no idea. Suggestions welcome.

It's not possible in general for games, I think.  You have to
specifically engineer new interaction modalities to to address
ability-limited situations.


> "fancy checkboxes"
> Ideal would be if CSS had more power here to make it possible to style
> the checkbox directly, rather than having people use canvas. For
> example if browsers would implement the 'content' property on
> non-pseudo-element selectors this would likely go a long way. That way
> people could do things like:
>
> input[type=checkbox]:not(:checked) {
>  content: url(unchecked.png);
> }
> input[type=checkbox]:checked {
>  content: url(checked.png);
> }
> input[type=checkbox]:not(:checked):active {
>  content: url(activeunchecked.png);
> }
> input[type=checkbox]:checked {
>  content: url(activechecked.png);
> }
>
> For sites that didn't want to use a static image but rather a
> generated canvas, something like the -moz-element value should work
> quite nicely:
>
> input[type=checkbox]:not(:checked) {
>  content: -moz-element(#checkboxchecked);
> }
> and so on. See [1] for a full feature description
>
> I believe webkit has a similar feature. Obviously all parties need to
> agree on a single solution here so that we can deploy non-prefixed
> properties.

The 'content' property needs another knob to make the image act like a
replaced element (dbaron suggested just using a 'replaced' keyword
alongside an image to change the behavior).  But otherwise, yeah,
that's exactly right.  I have the element() function specced in Image
Values as well.


> "rich text editing"
> I think that the only good solution here is to severely improve
> contentEditable. Currently contentEditable is a pain for authors to
> use because it doesn't provide a low level API, only high-level things
> like execCommand. It also works dramatically different in different
> browsers and with lots of different bugs in all browsers. It's really
> quite terrible. It's not surprising that some developers have said
> "screw it" and attempted to do better using canvas.
>
> There's been some ideas floating around within mozilla for what type
> of API we should expose, but so far no one has had the time to
> prototype anything. I really think this needs to be made a higher
> priority on the web platform in general. Not just to make text editing
> more accessible for AT users, but for non-AT users as well.

Agreed here.  Trying to do rich text editing in canvas is just such a
horrible idea.  It's really the worst.  People will continue trying to
make it work, and they'll continue failing horribly and going back to
letting the browser handle most of the pain.  We just need to make it
easier to do that, as you say.

~TJ

Received on Friday, 8 July 2011 19:03:08 UTC