Re: Alternative Canvas proposal from Charles

Replies to Rich and James...

On Mon, 21 Jun 2010 16:30:55 -0700, Richard Schwerdtfeger  
<schwer@us.ibm.com> wrote:

> James Craig <jcraig@apple.com> wrote on 06/21/2010 04:29:46 PM:
>> On Jun 21, 2010, at 1:48 PM, Charles McCathieNevile wrote:
>>
>> > …feel free to re-post as much/little as you like to the group...
>> >
>> > On Mon, 21 Jun 2010 13:00:24 -0700, James Craig <jcraig@apple.com>
>> >> On Jun 18, 2010, at 11:26 PM, Charles McCathieNevile wrote:
>> >>
>> >>> On Fri, 18 Jun 2010 22:59:10 +0200, James Craig <jcraig@apple.com>
>
> To Charles: One concerns I have with only using are map elements is
> aria-activedescendant. Say I have a list box and I want to draw visible
> focus on list box items managed by its parent. You really don't want to  
> put the list items in the tab order. So,

> <map>
> <div role="listbox" aria-activedescendant>
>    <div role="option" id="op1">guacamole</role>
>    <div role="option" id="op2">queso</role>
> ...
>
> </div>
> </map>
> Were you thinking about placing a map around the option with a shape?
> <map>
> <div role="listbox" tabindex="0" aria-activedescendant="op1">
>    <div role="option" id="op1" shape="rect" coords="">guacamole</role>
>    <div role="option" id="op2" shape="rect" coords="">queso</role>
> ...
>
> </div>
> </map>
>
> I am trying to see how this would work. Which focus shape gets drawn? I
> don't want it to be the list box. Hence, do we really want to dump the
> rectangle drawing function?

I don't understand the interaction model here. Do you want to make the  
entire list visible? Put a tabindex on the divs, ro make them interactive  
elements in the first (eg a elements, or area elements with alt text) and  
the user agent manages the focus for you including drawing the focus on  
the canvas. See Steve's demo -  
http://www.paciellogroup.com/blog/misc/canvas-pie/pie.html and tab around  
it.

> The second problem is switching the desktop to large fonts or switching  
> to high contrast mode. If we hard code the coordinates isn't this going  
> to be an issue. Ideally we would want to have the coordinates be a  
> function of em height.

Yeah, you do for large fonts. Good practice would be to code the thing in  
an em size, which means finding the em size through javascript and then  
using that to set your scale - including the size of your canvas element  
in the first place. So that should be a global function in the canvas  
drawing code, used to scale more or less everything. (In the common case,  
people aren't going to do that. A bit of library code that basically  
converted canvas to having an internal viewBox/coordinate space and a  
canvas size set according to the size of an em, as you can do in SVG,  
would be a helpful addition to canvas in general, but my proposal doesn't  
specifically address that and I think it is an orthogonal issue).

I imagine that you would want to know if you are in high contrast mode,  
and change the canvas accordingly, but I don't know if you can find that  
out right now. Which is an issue, but not directly related, and I don't  
understand how it affects the size in particular although I can see why  
you might want to change the sizes in high contrast.

>> >> <!ELEMENT MAP - - ((%block;) | AREA)+ -- client-side image map -->
>> >> http://www.w3.org/TR/REC-html40/sgml/dtd.html
>> >>
>> >> I must admit I had never noticed that HTML 4.01 allowed block
>> content in MAP.
>> >
>> > In HTML 4.01 only area elements or a elements can have shapes/
>> coords attributes, which is why the change proposal now adds them to
>> every element. As noted, that is slightly overkill, but if they are
>> not inside a map they simply have no effect so I don't *think* it is
>> problematic, and it seems simpler than listing them for "almost
>> every element...".
>>
>> This sounds to me like the idea is to keep the "shadow DOM" idea,
>> but have the accessible tree as a descendant of the MAP element
>> rather than inside the CANVAS element directly. Is that correct?

You got it pretty exactly.
>> If so, I like it. Simple cases could use plain old AREA siblings,
>> but more complex examples could have as deep a DOM tree as needed.
>>
>> > So in HTML 4.01 you would have to use a elements for a lot of
>> stuff, which still lets you do things like make
>> >
>> > <p contenteditable><a href=# onclick="foo()" shape="rect"
>> coords="...">This is a fake form
>>
>>
>> Why an anchor and not this?
>> <map …>
>> <p contenteditable tabindex="0" role="textbox" onfocus="foo()"
>> shape="rect" coords="...">This is a fake textfield
>> </map>

In the HTML 4/4.01 model you couldn't put the shapes and coords onto a p  
element - which is why that is a separate part of my proposal.

>> PS. I also appreciate that this will allow polygons, which were
>> dropped from the previous proposal.

And path shapes as with bezier curves, etc. which would better match the  
shapes people use - designers would scream if they thought their beautiful  
designs were going to be rendered with the more-or-less focus outlines  
that Steve's example has to work in current browsers... BTW that idea came  
 from something I recall Maciej saying, so you might want to ask him to  
look at it and see if I interpreted what I remembered him saying in a sane  
way.

cheers

Chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

Received on Tuesday, 22 June 2010 00:05:30 UTC