[webkit-dev] image maps to be focused via tab

[Rob Burns]

On Nov 14, 2008, at 4:01 PM, Maciej Stachowiak wrote:

>
> On Nov 14, 2008, at 9:15 AM, Darin Adler wrote:
>
>> On Nov 14, 2008, at 12:24 AM, browserwk wrote:
>>
>>> Before list, i assume html page have only one <img> and <map>(also  
>>> one
>>> <area>) tag, but also they are bounded.
>>>
>>> In order to focus navigate via tab, i did follow things.
>>> 1 to identify <img>,<area> tag
>>> I can get the <img> or <area> node from
>>> Document::nextFocusableNode
>>> Document::previousFocusableNode.
>>>
>>> 2 get absolutely position
>>> Also, i had got the position of the <img> and each <area> node with
>>> nonstandard way, in any way.
>>> If i use areaNode->renderer(), i will got NULL.
>>> I didn't know the reason.If u can, tell me more.
>>>
>>> 3 to focus <area> node
>>> In this step, i fail to focus the <area> node, moreover didn't see  
>>> the
>>> focus ring.
>>> And i found the <area> node never pass through the  
>>> isKeyboardFocusable()
>>> function.
>>> So, some questions
>>> <1> I want to know the factor that a node need be focusable, just  
>>> like
>>> <area> node.
>>> <2> Can i render the focus ring, when i got the <area> node and it's
>>> absolutely postion ?
>>
>> This doesn't sound like the right approach. To make this work the  
>> approach would not to be write new code to navigate, but rather to  
>> change the existing code so that it will do this when necessary.
>>
>> Assuming the page has only one <img>, one <map>, and one <area>  
>> seems completely wrong, and I'm not sure it's helpful to designing  
>> a solution.
>>
>> The premises behind your questions <1> and <2> are wrong so I  
>> really don't see how I can answer the questions.
>>
>> Sorry, I'd love to help, but I'm stuck here.
>
> One particularly wrong aspect of the original assumption is that in  
> practice, a single <map> and all its <area>s can be used by multiple  
> <img> elements. So representing focus of individual image map active  
> areas by making the <area> node focused won't really work - it  
> doesn't fit into the single focus ring model, since just focus on  
> the <area> node doesn't tell you which image map is active.

Let me add that image maps also apply to input elements of type image  
and object elements when they embed a still image (content-type image/ 
*).

I don't have the WebKit code handy at the moment, but here's some  
thoughts on this. I think this should be handled through adding more  
support for image maps. This could be done by changing the  
RenderReplaced class and the attach() method to deal with img, object  
and input elements that have a valid value for the usemap attribute.

1) add a RenderArea subclass of RenderBox (a subclass that allows  
RenderBox to be not only rectangular, but also circular and a polygon  
and applying all CSS box rules like any RenderBox, but not necessarily  
as a rectangle)

2) attach RenderArea boxes for each child of a HTMLMapElement just as  
one would for other child nodes (these RenderArea objects should be  
added to the RenderImage objects as child objects of the RenderImage  
containing block, for each RenderImage using that image map)

3) when rendering the replaced element its corresponding  
RenderReplaced, also add copies of the RenderArea instances in the  
appropriate place on the replaced element's RenderBox (the positioning  
would come from interpreting the image maps's area coordinates as CSS  
pixels and transforming them into )

4) then the RenderArea boxes should be added to the FocusController  
architecture just like any other focusable objects (this likely  
requires something like a shadow element added to the img, input or  
object element in the tree)

Just some quick thoughts on the topic. I admit the treatment of AREA's  
as CSS boxes is unorthodox, but it will degrade gracefully in other  
engines and it will make WebKit even more exceptional. This approach  
allows image map areas to participate in the render and navigation  
architecture in the same as other boxes. It also gets us CSS box model  
on areas as well and even improving title/tooltip support (see e.g.,  
this bug[1]).

Take care,
Rob

[1]: <https://bugs.webkit.org/show_bug.cgi?id=15035>