[Webkit-unassigned] [Bug 17513] Add ability for image maps to be focused via tabbing

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Jan 22 21:13:05 PST 2010


https://bugs.webkit.org/show_bug.cgi?id=17513





--- Comment #9 from chris fleizach <cfleizach at apple.com>  2010-01-22 21:13:03 PST ---
Thanks for your comments Darin. Will address everything not mentioned here.
Please see the below.  

> >  bool HTMLAreaElement::supportsFocus() const
> >  {
> > -    // Skip HTMLAnchorElements isLink() check.
> > -    return HTMLElement::supportsFocus();
> > +    // As long as this is a link and the tabIndex was not explicitly set to -1.
> > +    return isLink() && Node::tabIndex() != -1;
> >  }
> 
> Are you sure this can’t just be a call to tabIndex()? As far as I can tell it
> should give you the same value, and the code would be less strange.
> 

An AREA element might also have a nohref attribute or just no link. in that
case, it should not be focusable or support focus.

> I’m not sure this is the right rule. Will this change tabbing for all
> documents? Why is this different from the rule for links?
> 

you're right. looks like the tabIndex is taken care of in
Node::nextFocusableNode

> > +    Path getPath(RenderObject*) const;
> 
> Normally we don’t use the word “get” in the names of functions that return a
> value. We reserve it for functions that return values in unusual ways, with out
> arguments. I think the name of the function is not clear enough. Sure it's a
> path, but what does the path represent?

This method was right below 
IntRect getRect(RenderObject*), so was following convention. 

Do you think

getPathBoundary() is better. 
It's the path of the area element, since an area can be a polygon, circle, etc.
Drawing a blank on other ideas. Perhaps a better comment?


> > +    // FIXME: Clip the paths to the image bounding box.
> 
> Why aren't you doing that? Seems easy to do.

Looked into it and its a lot harder than it sounds when you just have a
CGPathRef. ImageKit takes a lot of code to implement IKPathClipToRect.


> Did we discuss whether the change in tabbing behavior is good all the time? Did
> you talk to anyone else who works on WebKit about that change?

There has been no discussion on this. I have assumed that this was just a bug,
since you can always tab to links and these are links. This behavior also works
in all other browsers. Should I bring this up on webkit-dev?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


More information about the webkit-unassigned mailing list