Re: [VE][html5] conflicting errors for <area> without a href

On 27/10/2011 8:24 PM, Jukka K. Korpela wrote:
> 27.10.2011 3:29, kunda wrote:
>
>> Here's the validation link:
>>
>> http://validator.w3.org/check?uri=http%3A%2F%2Ftinyurl.com%2F6yrcw5c&charset=%28detect+automatically%29&doctype=Inline&group=0&ss=1&verbose=1 
>>
>
> Thank you - it was a somewhat surprising way of showing the source but 
> quite sufficient for identifying the issue.
>
> The issue is reproducible using the minimal document
>
> <!doctype html><title></title>
> <map name=m>
> <area alt="">
> </map>
>
> It's the alt attribute that causes the error message about missing 
> href. It is adequate to issue an error message on the basis of this:
> "If the area element has no href attribute, then the area represented 
> by the element cannot be selected, and the alt attribute must be 
> omitted."
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-map-element.html#the-area-element 
>
>
> That's a way of saying that if the alt attribute is present, the href 
> attribute must be present.
>
> The error message could be clearer, though. I've created the bug report
> http://bugzilla.validator.nu/show_bug.cgi?id=870
> (which also addresses some other <area> issues).
>
Thank you for that, and since I posted that source I have found out that 
without the href attribute webkit and presto engines don't allow 
keyboard navigation to an <area> tag which meant my use of the :focus 
pseudo element to make it accessible for touch devices that can't 
trigger :hover would fail, and since webkit has an additional bug that 
means :hover doesn't work on <area> at all ( 
https://bugs.webkit.org/show_bug.cgi?id=15035 ) I decided to go with 
adding in the href attribute.

Instead of an empty href="" attribute I chose a self referencing one, 
like so:

<area shape="rect" coords="90,0,320,56" title="Lord of the Rings" 
alt="LOTRh" id="LOTRh" href="#LOTRh">

with this as the CSS:

area[alt$="Rh"]:hover ~ img#nv, area[alt$="Rh"]:focus ~ img#nv, 
area[alt$="Rh"]:target ~ img#nv {
-moz-transition: -moz-transform-origin 2s, -moz-transform 2s ease-in;
-moz-transform-origin: 210px 0px; -moz-transform: scale(1.5);
-webkit-transition: -webkit-transform-origin 2s, -webkit-transform 2s 
ease-in;
-webkit-transform-origin: 210px 0px; -webkit-transform: scale(1.5);
-o-transition: -o-transform-origin 2s, -o-transform 2s ease-in;
-o-transform-origin: 210px 0px; -o-transform: scale(1.5);
-ms-transition: -ms-transform-origin 2s, -ms-transform 2s ease-in;
-ms-transform-origin: 210px 0px; -ms-transform: scale(1.5);
transition: transform-origin 2s, transform 2s ease-in;
transform-origin: 210px 0px; transform: scale(1.5);
}

which means a click on a zoomed-in area of the image stays zoomed in, or 
the click causes the zoom in on buggy webkit, Tab on the keyboard now 
works panning from one zoomed-in area to the next, and maybe even IE9 
with only support for transforms but not transitions (I see IE10 will 
support transitions)) would do a snap zoom to the area on click 
(untested as I only have access to Windows XP). This of course means now 
the browser navigation buttons work, and an area can be zoomed in on 
using an anchor link elsewhere in the document. Accessibility wins all 
round without any javascript! :)

Received on Thursday, 27 October 2011 11:14:46 UTC