Re: another example of HTMl 5 canvas with interactive UI elements.

Joshue O Connor wrote:
> Lachlan Hunt wrote:
>> Joshue O Connor wrote:
>>> This kind of thing seems to me a ridiculous level of complexity and a
>>> retrograde step in web development.
>> Rather than simply rejecting the idea outright, could you elaborate on
>> specifically what was wrong with the techniques I described?
>
> Its clever, in that - yes it /could/ work and fair play for you having
> the smarts for coming up with it. However, its just (and no slight on
> you) very complicated. In particular if you look at this through the
> lens of an author who would have to do the /extra/ steps you describe to
> make stuff accessible. They just won't bother. When a declarative markup
> language is used it has inherent properties that are recognised by AT.
> <canvas>  etc is just a drawing API with no such properties - any
> solution will be a hack really.

Indeed.  But the advantage of looking at solutions that use nothing more 
that what we already have available today is that it helps to identify 
possible concepts to build upon, specific issues to address and, if 
anything we have already works well, to avoid needlessly re-inventing 
the wheel.

> Yes, the WG could strongly advocate the use of<canvas> for nothing
> other than eye candy or pretty pictures. In fact the spec already pretty
> much states that it shouldn't be used when there is a better solution -
> not that many will listen as the genie is already out.

This doesn't really sound like a solution to the problems, so much as it 
sounds like trying to stop a wave coming up the beach by standing in the 
water in front of it.  I just don't think it will be too successful.  It 
seems clear that people are going to keep finding lots of innovative 
ways to use canvas to solve their problems if they perceive it as having 
some advantage over the alternatives.  So instead of pushing against 
developers, I think it's better to work with them to improve the tools 
they want to use.

John Foliot wrote:
> Lachlan Hunt wrote:
>> One relatively simple way to make that particular example accessible
>> would be to make use of an image map.  The technique could work
>> something like this.
>>
>> Overlay the canvas with a stretched transparent image of the same size
>> has the canvas.  The image then needs to be associated with an image map.
>
> What size is this stretched image? 1024 X 768? 800 X 600? Something else?
> How are you going to know?

Making two elements the same size and positioning one on top of the 
other isn't really that hard.  Working within the constraints of using 
only existing tools, that was just a hack to workaround the limitation 
of canvas not having its own usemap attribute.

>  upon which more javascript then writes shifting icons complete with
> dynamically re-written  <area>  coordinates. Really? And this is
>  "relatively simple" to do?

In this particular case, the icon movements merely transitional states 
and the areas wouldn't need to be moved frame by frame with them.  They 
would just need to be positioned over their final positions after 
they've moved, which really isn't that difficult.  Admittedly, this 
would be a lot more complicated where the areas do need to be moved 
frame by frame.

>>>> For each icon represented on the canvas, an associated<area>  element
>>>> needs to be created by the script with its co-ordinates set to the
>>>> position of the corresponding icon.  Appropriate alternate text is
>>> also
>>>> needed for each one.  When icons on the canvas are moved, the image
>>> map
>>>> areas need to be dynamically updated also.  With each area being
>>> focussable, this would add support for keyboard navigation.
>
> OK, so how many developers out there do you think are going to do
> duplicate amount of work (as you just described),

Yes, that is certainly a problem that would need to be addressed in the 
final solution.  But it's a start and I think the concept of somehow 
marking active regions of a canvas which can receive and respond to many 
different types of input is at least conceptually on the right track. 
Finding a solution that makes that easier, perhaps by integrating it 
into the canvas API itself, might help with that.

In IRC, some of us discussed a few more techniques that built on these 
concepts to find ways of doing exactly that, including the following:

* An API to declare active regions which can receive focus and events, 
including both keyboard and mouse.  These could be positioned either by 
explicitly specifying positions, or have it more automatic somehow based 
on the areas in which the script draws. This may have some advantages 
for authors that would otherwise have to calculate what was clicked 
manually based on the mouse position.

* APIs that, while the canvas is focussed, let script take manual 
control of navigation events and be able to respond with appropriate 
information.

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Received on Friday, 10 July 2009 08:44:25 UTC