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>
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
