W3C home > Mailing lists > Public > public-html@w3.org > January 2009

Re: HTML is a declarative mark-up language

From: Robert J Burns <rob@robburns.com>
Date: Thu, 29 Jan 2009 12:48:29 -0600
Cc: HTML WG <public-html@w3.org>
Message-Id: <843CB843-7EC6-462C-9472-F0B9DA77A30C@robburns.com>
To: Boris Zbarsky <bzbarsky@MIT.EDU>

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,
Received on Thursday, 29 January 2009 18:49:07 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:42 UTC