21787 2013-04-23 13:32:09 +0000 Setting <area>.href to a relative URL should set the content attribute to the listeral value instead of resolved value, to match browsers and what the spec requires for other reflecting URL attributes [...] 2016-01-24 05:34:22 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#the-area-element P3 normal Unsorted 1 contributor ian d ian mike contributor oldest_to_newest 86550 0 contributor 2013-04-23 13:32:09 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-map-element.html Multipage: http://www.whatwg.org/C#the-area-element Complete: http://www.whatwg.org/c#the-area-element Referrer: http://www.whatwg.org/specs/web-apps/current-work/multipage/ Comment: Setting <area>.href to a relative URL should set the content attribute to the listeral value instead of resolved value, to match browsers and what the spec requires for other reflecting URL attributes (and what the spec required before adopting URLUtils) Posted from: 90.230.217.68 User agent: Opera/9.80 (Macintosh; Intel Mac OS X 10.8.3) Presto/2.12.388 Version/12.15 86564 1 ian 2013-04-23 15:36:19 +0000 HTML doesn't define .href anymore. Reassigning to URL. Anne, if this should be fixed in HTML, let me know how I should do it. Thanks! 86680 2 annevk 2013-04-24 15:55:23 +0000 https://github.com/whatwg/url/commit/1d866b441eef031481bffaa0df9f43630e6fe62e 88760 3 ian 2013-06-05 20:25:21 +0000 This broke Location.href instead. The update steps for Location.href need to be passed an absolute URL, since the URL is immediately used to navigate. Reassigning to Anne so he can decide how we should fix this. :-) 88761 4 contributor 2013-06-05 20:26:42 +0000 Checked in as WHATWG revision r7908. Check-in comment: Update to match recent URL spec changes (this fixes a.href/area.href, but note that this breaks Location.href instead; see the bug for details) http://html5.org/tools/web-apps-tracker?from=7907&to=7908 88821 5 annevk 2013-06-06 13:31:38 +0000 I don't see how that's true. You pass the value to assign() or replace() which both parse it relative to a base URL just fine. 124689 6 d 2016-01-24 05:34:22 +0000 I believe this has been fixed as of the recent overhaul of URL, Location, and HTMLHyperlinkUtils.