Re: HTML is a declarative mark-up language

Robert J Burns wrote:
> 
> On Jan 29, 2009, at 12:06 PM, Boris Zbarsky wrote:
> 
>> Robert J Burns wrote:
>>> 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.

In that case, I don't see the point you're trying to make in the 
paragraph above.  Is it that somehow now using the <a> is only worth it 
because it's shorter, whereas before it was both that and the fact that 
it was morally more pure?

>> (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.

If someone wants to put your fragment that's targetable into their 
document, they cannot put it inside an <a> if you use an <a> as your 
targetable node.  If they try, they will either have their <a> closed 
early (if they're inserting on the source level) or create a document 
that cannot be serialized as valid HTML (if they're inserting on the DOM 
level).  There's no such restriction for <span>.

For example, solely using <a> for your targets means you can't do 
something like this (done without <a>, of course):

<style>* { opacity: 0.5; } :target, :target * { opacity: 1.0; }</style>
<section id="target-this-to-highlight-section">
   <p>Some text here.</p>
   <pre id="this-happens-to-be-idl-for-the-interface-we-are-defining">
     ...
   </pre>
</section>

That is, once you can target anything you want, the special parsing 
rules for <a> actually make it a detriment to use it as a targetable 
node, since there are many cases when targetable things can nest.

> 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.

Ah, indeed.  I forgot that HTML4 already introduced targeting of 
arbitrary IDs.  XHTML 1.1 then dropped the "name" attribute for anchors 
as conforming, since now IDs could be used instead.  Is the claim that 
this was a mistake?

> 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).

That's true.  The only reason <a name> was conforming, as far as I can 
tell, was as a transitional step from there being no other way to target 
links in HTML3.2.  So you could write the HTML4 <a name="x" id="x"> and 
expect links to #x to work no matter which approach the UA was taking.

Maybe we do want to keep documents that use this conforming in HTML5, 
but what is the benefit?  I don't believe we necessarily have a goal 
that any conforming HTML4 document be a conforming HTML5 document, so 
this is something to decide on a case-by-case basis.

-Boris

Received on Thursday, 29 January 2009 20:07:49 UTC