- From: Robert J Burns <rob@robburns.com>
- Date: Thu, 29 Jan 2009 12:00:04 -0600
- To: Sam Ruby <rubys@intertwingly.net>
- Cc: Lachlan Hunt <lachlan.hunt@lachy.id.au>, HTML WG <public-html@w3.org>
Hi Sam, On Jan 29, 2009, at 6:33 AM, Sam Ruby wrote: > > Lachlan Hunt wrote: >> Furthermore, the definition of hyperlink, which is immediately >> followed by the definition of the href attribute, states: >> "The a, area, and link elements can, in certain situations >> described >> in the definitions of those elements, represent hyperlinks. >> The href attribute on a hyperlink element must have a value that >> is a >> valid URL. This URL is the destination resource of the hyperlink." >> Here it is clearly stated that the href attribute gives the >> *destination resource of the hyperlink*. How is that difficult to >> understand? > > If coming to that fresh, it is fairly straightforward. But if you > have any history or take a look at any non-trivial subset of > existing web pages, it is either a bit confusing or incomplete. > > One other use anchor elements used to have is as a target of a link. > That usage may not be considered conforming, but it still is in wide > use. Many pages will duplicate the value of id attributes as name > attributes and put both on <a> elements because some browsers which > now enjoy at most trace market share do not support id. > > Clearly the trend now is to associate URI fragment identifiers with > HTML id attributes, and id attributes that can serve as the target > of a hyperlink can appear on many elements, and not just ones that > are named <a>. The current draft for "HTML 5: A vocabulary and > associated APIs for HTML and XHTML" choses to focus on providing the > information as to why this element is unique. I would add that even without the legacy baggage it makes a lot of sense to continue to support <a> as a destination anchor. When an author want to make a specific phrase available as a document fragment that is not already wholly and completely enclosed within an element, the author can either use a <span> element or a <a> element. However, the HTML4.01 <a> element is both more specific (it is supposed to be an anchor—destination in this case) and more compact than <span>. However, this is another case where HTML5 needlessly changes the meaning of an element in the HTML namespace which creates namespace collisions and also removes a valuable meaning of the element that authors had available in HTML5. When taken one issue at a time, the erosion of the benefits of HTML4— the damage inflicted by HTML5—seems small and easily brushed aside. But when we look at all of the issues in total, the problems with the HTML5 draft are quite severe (DOM erosion, loss of clear semantics, accessibility features removed without replacement, etc). And if anyone who thought that HTML5 should be an unambiguous improvement over HTML4, the issues seem all that much worse. Take care, Rob
Received on Thursday, 29 January 2009 18:01:02 UTC