Re: HTML is a declarative mark-up language

On Jan 29, 2009, at 3:41 PM, Boris Zbarsky wrote:

> [I assume this was off-list on purpose]
> Robert J Burns wrote:
>> 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
>
> Useful for what, though?  I agree it had an additional meaning.  I  
> question the usefulness.
>
>> (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.
>
> This is true.  The same is true of various other things that XHTML  
> 1.0/1.1 and HTML 4.01 deprecated...
>
>> Why do they need to put the fragment in the <a> element as is? What  
>> use case are you thinking about?
>
> Because they want to make the fragment an actual link?
>
> I'm thinking things like, say, making an inline SVG image into a link.
>
>> 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).
>
> I'm not sure what you'e asking.
>
>> 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.
>
> That's true, but there is no such problem with the semantics of  
> _targetable_ elements.  There is, of course, a problem with nested  
> links, which is where the original prohibition on nesting <a> comes  
> from.
>
>>> 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?
>
> You're saying that it's a mistake to be dropping it in HTML5.  Why  
> is XHTML 1.1 different?

I'm not saying anything of the sort. I DON'T CARE ABOUT DROPPING THE  
'NAME' ATTRIBUTE. Sorry for yelling, but you keep putting those words  
in my mouth and I never said any such thing. Again Boris you don't  
even bother to read what others write on this list, you simply jump  
into the conversation with unrelated comments.

>> I'm not talking about <a name> at all. I don't care about the  
>> 'name' attribute.
>
> Wait.  The whole discussion was about <a name> no longer being  
> conforming HTML in HTML5.  If you're not talking about that, what  
> _are_ you talking about?

I'm talking about using the 'a' element as a destination anchor (which  
can just as well be done with an id 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.
>
> Anchor in the sense of link origination point or link destination  
> point?  Or both?

HTML5 limits anchor to only an origination or source anchor. So I'm  
talking about the part that is dropped from XHTML1.1 (and what came  
before) which is the use of anchor as a destination anchor.

>> HTML4 had a dedicated element for that. HTML5 does not? Why?
>
> HTML4 and HTML5 both have a dedicated element for an outgoing link:  
> <a>.  HTML4 allows incoming links to target any node with an id or  
> any <a> node with a name.  HTML5 allows incoming links to target any  
> node with an id, though UAs are also required to keep the HTML4  
> behavior.  A document containing an <a> with a "name" attribute is  
> not conforming HTML5.

Neither is a document containing an "a" element with an "id" attribute  
unless that "a" element is simply waiting for an "href" attribute to  
arrive from the DOM. This is what  the conversation Leif and I have  
been discussing.

>> 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.
>
> This is a very good question, and quite different from the question  
> you actually raised on the mailing list.

No, this is the same question I raised.

>> 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.
>
> I think Leif's reading is incorrect, for what it's worth.

I might agree with you, but my point is given all of the bizarre  
subtle changes to semantics in HTML5, it is not surprising to see many  
people might come to read it that way.  What Ian complains about HTML4  
doing to implementors (providing insufficient norms and guidance that  
makes sense), he is making HTML5 do to authors. It is not surprising  
if authors familiar with previous HMTL vocabulary specifications will  
retreat to those to better understand HTML5. So the question is if  
we're going to continue to promote markup sections in the HTML5 draft  
that force authors to look for normative advice elsewhere, what's the  
point of even having those ambiguous norms in the HTML5 draft in the  
first place. Let's leave those norms to be specified by someone with a  
better understanding of the issues and the needs of authors and reduce  
the work of the current HTML5 draft to expressing the norms for  
implementors only (UA conformance norms only).

Take care,
Rob

Received on Thursday, 29 January 2009 22:43:24 UTC