- From: Robert J Burns <rob@robburns.com>
- Date: Thu, 29 Jan 2009 12:48:29 -0600
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- Cc: HTML WG <public-html@w3.org>
On Jan 29, 2009, at 12:06 PM, Boris Zbarsky wrote: > Robert J Burns wrote: >> 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. > > I'm confused. What exactly in HTML5 keeps you from using <a> as the > element to wrap your fragment? Nothing, but the discussion is over the prose definition of the semantics of the <a> element. > (Note that doing that might cause parsing issues depending on where > it's inserted, but that's not new with HTML5; HTML5 just gives you > the option of avoiding said issues by using <span>, as you point out.) I'm not familiar with the parsing issues you're referring to here. Also, the <span> element was also available in HTML 4 so HTML5 doesn't introduce the option of a <span> element, that was already available before. However, HTMl5 does narrow the semantics of the <a> element so that while the UA processing would generally work, the use of the <a> element I'm describing would be document non-conforming (though it was document-conforming in HTML4). Take care, Rob
Received on Thursday, 29 January 2009 18:49:07 UTC