This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The a element is missing the coords and shape attributes, defined in HTML 4.01, section 12.2 and 13.6.1. The attributes must be defined similar to those on area. As such, the processing the model defined in HTML5-4.8.14.2 must be corrected as following: - the third step in algorithm for extracting the /areas/ must say: "If the /map/ contains only one or more _area_ element, collect all those, else collect all _a_ element descendant of the having both a valid _shape_ and _coords_ attribute. The collected elements are the /areas/" (compatible with the requirement in HTML4.01) Then all furhter references to the area element must be removed from that section.
Despite the HTML4 spec having the coords and shape attributes as valid attributes on <a>, they don't actually seem to be supported in most browser engines (apparently they're only supported in Gecko). The draft spec itself and the "HTML5 differences from HTML4" documents explicitly list the coords and shape attributes on <a> as absent/obsolete attributes in HTML5. http://www.whatwg.org/specs/web-apps/current-work/multipage/obsolete-features.html#other-elements,-attributes-and-apis http://www.w3.org/TR/html5-diff/#absent-attributes
From a simple testcase, they're only supported in Opera, but this is not different (one out of 4 anyway). This does not make the feature deprecate, either. I want a rationale for abolishing such useful feature, given that is not difficult to implement and a lot of CSS hacks are employed by authors to achieve similar results.
(In reply to comment #2) > From a simple testcase, they're only supported in Opera, but this is not > different (one out of 4 anyway). So that means there have never been two interoperable implementations of this particular feature. Which means that the feature never should have been part of the HTML4 standard to begin with. > This does not make the feature deprecate, either. I want a rationale for > abolishing such useful feature, given that is not difficult to implement and a > lot of CSS hacks are employed by authors to achieve similar results. We're not abolishing the feature. If it can't be used interoperably among multiple UAs, then it's not actually a useful feature at all. It might be a _potentially_ useful feature, but the fact most browser vendors have not implemented support for it despite it being part of HTML4 for more than 10 years strongly suggests that there is not enough market demand from users for that feature to compel the vendors to actually implement it. In other words, nobody cares about the feature (or even knows about it) enough to make it worthwhile for browser vendors to implement it. The lack of existing support for that feature makes this case very different than the case of discussing whether or not to include a feature like, say, <font>, that is already interoperably supported. To put it in other terms: We will not be able to transition the HTML5 spec out of CR unless we have two interoperable implementations of each feature in the spec. Given the circumstances I outlined above, I am telling you that it is extremely unlikely that we will get two interoperable implementations of the shape and coords attributes on the <a> element, and because of that it is basically a waste of all of our time to include it in the spec at all given that we will almost certainly need to drop it from the spec later (when transitioning out of CR). Can you demonstrate either that there are actually any significant number of other users that want this feature supported, or that you have any indication at all that browser vendors are will somehow change their minds for some reason and implement support for coords and shape on <a>?
Gecko does have code to support this; I'm not sure what this mysterious "simple testcase" is that isn't linked to from this bug, so I can't tell you why you see the behavior you see. That said, I'd be _very_ happy to remove this code from Gecko. I've never seen this code exercised in practice.
Created attachment 715 [details] The "simple test case" Here it is. On Firefox 3.5, Safari 4, IE 8 I cannot click the image in any way. On Opera 10 I can click the center and the border, with different links. If an implementation is provided by Firefox, we have two interoperable implementations, which is a point in favor of reintroducing the feature.
> We have two interoperable implementations Well, as your test shows they're not exactly interoperable (for imagemaps in general, though). Gecko does not support referencing imagemaps by ID in HTML4, only in XHTML. s/id/name/ in your testcase makes it work. That said, I would still be very very happy to rip this code out of Gecko. As I said, I have never seen it used.
(In reply to comment #6) > > We have two interoperable implementations > > Well, as your test shows they're not exactly interoperable (for imagemaps in > general, though). Standards are written for that: to ensure consistent behavior across multiple browsers. > Gecko does not support referencing imagemaps by ID in HTML4, only in XHTML. > s/id/name/ in your testcase makes it work. Tried with name, and it works. Sorry then, my fault! > That said, I would still be very very happy to rip this code out of Gecko. As > I said, I have never seen it used. > There are a lot of features that have never been used, but they're still present. This one should not be dropped because it allows to write image maps that are more descriptive, putting the alternative text directly inside the long image description and allowing to mark some areas as important (strong). I think that this example: <map name="city-map" id="city-map"> <p>This image is a satellite view of ExampleCity. You can click on the <a href="north" shape="rect" coords="0,0,100,100"><i>North Quarter</i></a> or <a href="center" shape="circle" coords="200,200,50">the town center</a>. <strong>Don't forget to visit <a href="examplemuseum" shape="circle" coords="375,375,20">the Example Museum of Everything</a> at <a href="examplemuseum-mapview" shape="rect" coords="350,350,50,50"><i>123 Example Road</i></a></strong> </p></map> <img src="examplecity-satview" usemap="#city-map" width="400" height="400" aria-describedby="#city-map"/> is much more accessible and easier to write and maintain than the equivalent <map name="city-map" id="city-map"> <area href="north" shape="rect" coords="0,0,100,100" alt="North Quarter"> <area href="center" shape="circle" coords="200,200,50" alt="Town Center"> <area href="examplemuseum" shape="circle" coords="375,375,20" alt="Example Museum of Everything"> <area href="examplemuseum-mapview" shape="rect" coords="350,350,50,50" alt="123 Example Road"> </map> <p id="city-map-desc">This image is a satellite view of ExampleCity. You can click on the <a href="north"><i>North Quarter</i></a> or <a href="center" shape="circle">the town center</a>. <strong>Don't forget to visit <a href="examplemuseum">the Example Museum of Everything</a> at <a href="examplemuseum-mapview"><i>123 Example Road</i></a></strong></p> <img src="examplecity-satview" usemap="#city-map" width="400" height="400" aria-describedby="#city-map-desc"/>
So, currently this bug has been marked as "resolved" for the wrong reasons: Giovannis's test case was wrong (using @id instead of @name). Thus we have at least two /current/ interoperable implementations: Firefox and Opera. In addition to that, we have some supporting implementations that were current a few years ago: IE5 for Mac and iCab 3. Thus we have probably previously had at least 4 interoperable version. (Which nullifies Michaels argument that HTML 4 should not have included this.) Also, reading the Microsoft documentation, it actually says that shape/coords works on <a> also (since IE6). OK, it doesn't work, but there were many things that did not work up until IE8, and hence there is hope that they could fix this in IE8.1, I think. Further, Google Doctype documents better IE script support for shape in <a> than in <area>: http://code.google.com/p/doctype/wiki/AShapeAttribute With regard to Webkit, then it is just quite buggy. For instance, it doesn't support image maps that uses OBJECT instead of IMG elements - it is generally very buggy w.r.t. OBJECTs. I also share Giovanni's view that <a> has many advantage over <area>, including accessibility advantages.
Like Boris indicates for Mozilla, Opera would also like to remove this code.
This bug predates the HTML Working Group Decision Policy. If you are satisfied with the resolution of this bug, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html This bug is now being moved to VERIFIED. Please respond within two weeks. If this bug is not closed, reopened or escalated within two weeks, it may be marked as NoReply and will no longer be considered a pending comment.
I object to closing this bug. EITHER this bug must be solved in accordance with how the bug filer suggested. OR an cross browser compatible solution with more or less the exact same features as <a coords=* shape=*>link text</a> has (with regard to accessibility and design pattern) must be *worked out* for the <area> element. I will focus on the OR option, to allow Ian or whoever to come up with something that I can accept. And in that regard, when Ian suggested removing <a coords=""> back in April 2005, he described a "workaround": http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2005-April/003514.html His solution went like this - i.e. he was suggesting to use a nearby <a> element sideby side the <area> element: <image src="foo" usemap="#foo"> <map id="foo"> <area coords= href= alt="Link text." ><a href= >Link text.</a> </map> In addition to this option, the HTML5 spec currently also allows us to place an <area> inside an <a> element which is more logical - a better design pattern. <a href="..."><area coords="..." href="...">...</a> However: A) How to actually use this workaround is not described/worked out in the spec. The spec must describe this. B) There are many open issues. * First and foremost duplication of link text, both inside @alt as well as inside <a>: <area alt="Link text." ><a href= >Link text.</a> Can this be avoided, for example when one is nesitng the <area> inside the <a>? (The accessibility issues are known since 2005 ... http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2005-September/004667.html ) C) The nesting option has many open questions: 1. Again, the general duplication question: is there anything we do not need to duplicate when we are nesting? 2. In particular: Do we need to use the @alt attribute when we nest it? Or can we skip it then, when nesting? Must it be present but empty? 3. If I place a @title in the <a> element, will it then be used also in the <area> element? 4. Is nesting cross browser compatible? Regarding C 4., then *no*, nesting is not fully cross browser compatible. There are issues with Mozilla browsers to be solved! Either through a change in what is permitted in the syntax. OR by giving authoring advice about how to be Mozilla compatible. Or both ways. The Mozilla issue is that when an <area>element is wrapped inside an <a> element, then it doesn't "see" the <area> element, and so the image map doesn't work. However, if you either provide at least a single dummy (also known as "boolean" ...) <area> element (which can be entirely empty) inside the <map> somewhere (but outside any of the <a> elements), then Mozilla browsers will be triggered to react to all <area> elements. Another way to trigger Mozilla browsers to see the <area> elements, is to place @coords and @shape on at least *one* of the <a> elements - this too will trigger them to see the rest of the <area> elements inside that <map> element. Somehow one or both of these *necessary* Mozilla workaround techniques needs to baked into the specication! One way to incorporate them into the spec would be to simply say that <a> *may* contain @coords and @shape *provided* that it is used as a wrapper around an <area> element. Regarding C) 3, then Opera and Firefox does the logical thing: If you provide a @title on the <a> element, then it is propagated to the <area> element. HTML5 does require that @title is propagated like this. But it seems necessary to specify with regard to <area>. Webkit and IE (IE8 in standards mode) does not propage the @title of the <a> element to the <area> element. D) Authoring requirements/advice: The spec should a) advice authors to use nesting, since this a better design pattern, with some advantages, for authors and users (less out of sync data) b) give advantages to those that use nesting (less duplications, e.g. no requirement to supply the @alt attribute etc) c) give advice about what to do when duplication is necessary for compatibility reason: make sure that @title of both <area> and <a> are identical. Make sure that @href says the same thing in both elements. d) specify exactly which features a nested <area> element will "inherit" from its parent <a> element - in order to spare authors from duplications (which is prone to errors): could it even inherit the @href value? E) Finally, this bug also relates to Charles proposes solution of accessibility for the <canvas> element via image maps.
Created attachment 828 [details] Demo of the issues that needs to be solved, if a@coords should be allowed to be dropped from HTML The attached document demos the isssues that I described when I reopened this bug.
Created attachment 829 [details] Demo of the issues that needs to be solved, if a@coords should be allowed to be dropped from HTML There was an error in my analysis of one of the two Mozilla nesting workarounds, due to an error in the test document (plus plus) - here I replace the test with a corrected version. See 1.3, variant 1 in the test: The correct analysis is that the @coords and the @shape attribute must be present on each <a> element. Thus, unlike what I said previously in this bug report and in the test document, it is not enough that only one of the <a> elements has @coords and @shape attributes. (However, the other workaround - and empty <area> element inside <map> - works as previously told.)
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: This bug is about whether <a coords> is conforming or not. Based on UA feedback, it was removed from the UA requirements and made non-conforming. This bug is not about extra examples or other material. Please file separate bugs for each request so that they can be tracked separately.
The bug-triage sub-team doesn't consider this bug to be task force priority.