W3C home > Mailing lists > Public > public-html@w3.org > February 2010

A@coords vs AREA@coords

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Thu, 25 Feb 2010 08:33:48 +0100
To: HTMLwg <public-html@w3.org>
Message-ID: <20100225083348899596.e95cd67d@xn--mlform-iua.no>
Tab Atkins Jr., Wed, 24 Feb 2010 23:37:50 -0600:

>> OK. Hopefully HTML4 replace their functionality with better things.
>> That is not the case w.r.t. <area>.
> What functionality is lost?  Is this useful functionality?  If it
> serves a valuable use-case, then it shouldn't be dropped.  Can you
> express such a use-case?

The problem with attributes versus elements is that attributes are 
subject to data rot. The <area> element requires use of an @alt 
attribute, whose content should be synced with a map. Whereas for <a> 
it is expected that there is content inside the element. Thus 
accessibility fallback is not required. Simpler. Less prone to data 
rot. Simpler to keep in sync. Accessibility more or less automatically 
taken care of. Elements simply has better accessibility than attributes.

It would be interesting to see some statistics of how much the alt 
attribute of <area> is used ... 

HTML4 has an example[1] of something that is not possible with <area>: 
links that works both inside and outside the image map.

	If there is a workaround, then it is at least not explained in the 
spec.). Even less to keep in sync! Less data rot.

I reworked the HTML4 example slightly and tried in Live DOM viewer. 
Works in released versions of Opera and Firefox. [2] With the wide 
support Firefox and Opera has today, this means that it has never been 
better support for this feature. ;-)

[1] http://www.w3.org/TR/html401/struct/objects#h-

[2] http://software.hixie.ch/utilities/js/live-dom-viewer/saved/386

leif halvard silli
Received on Thursday, 25 February 2010 07:34:24 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:58 UTC