Re: HTML is a declarative mark-up language

Hi Boris,

On Jan 29, 2009, at 2:07 PM, Boris Zbarsky wrote:

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

As usual, Boris, you're unable to listen to what others are saying.  
What I'm saying is that in HTML 4 <a> used to have a different meaning  
that was quite useful (as Leif has pointed out). Now in HTML 5, some  
of that meaning is to be removed so that authors cannot use the <a>  
element as they once did without violating the document conformance  
norms.

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

Why do they need to put the fragment in the <a> element as is? What  
use case are you thinking about? Why wouldn't the DOM manipulating  
author simply retrieve the document fragment contents of the <a>  
element and use it as they needed (which is what I understand the  
purpose is for).

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

Indeed, but sometimes there are reasons to restrict nesting too. We do  
not restrict nesting of "p" elements simply to annoy DOM manipulation  
authors. We do it because the semantics of a direct "p" descendant of  
a "p" element are unclear.

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

No, where would you possibly get that from in my remarks?

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

I'm not talking about <a name> at all. I don't care about the 'name'  
attribute. I'm talking about a fragment of phrasing that an author  
wants to make into an anchor and therefore wraps it inside an element  
for no other reason than to serve as an anchor. HTML4 had a dedicated  
element for that. HTML5 does not? Why? What use case are we solving by  
creating semantic confusion in redefining the "a" element. Keep in  
mind, I'm not against redefining any element at any time? I just want  
to see us be a little more careful about it and consider why we feel  
it is necessary.

Leif has taken a different reading here then me. One that I think many  
will take with all of the seemingly arbitrary semantic changes in  
HTML5. His reading is that now we have to read both the HTML4  
recommendation and any future HTML5 recommendation in tandem. Since  
HTML5 turns all of the semantics on their head in bizarre and  
unexplained subtle ways, then Leif concludes that the only way to  
understand HTML5 is to apply HTML4 to that as well. The alternative is  
difficult to grasp. Why would  a WG leave these semantic changes up to  
the whim of a single editor who either doesn't understand the  
semantics of HTML4 (which he often admits) or doesn't care to  
understand the views of the WG (or both). There are certainly absences  
in the HTML4 recommendation when it comes to implementation details.  
However, it now looks like Ian wants to exact vengeance upon the third- 
party authoring community because they had it better than the  
implementors with HTML4. Can't we all just get along?!

Take care,
Rob

Received on Thursday, 29 January 2009 21:42:25 UTC