Re: HTML is a declarative mark-up language

Hi Boris,

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

>
> Robert J Burns wrote:
>> 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).
> >
>
> Let's recap:
>
> Roy complained that the name attribute on <a> has been removed.  Ian  
> replied to that, Leif replied to Ian, Lachlan replied to Leif, Sam  
> replied to Lachlan.  You replied to Sam on that thread saying:
>
> "I would add that even without the legacy baggage it makes a lot of
>  sense to continue to support <a> as a destination anchor."
>
> and
>
>  "removes a valuable meaning of the element that
>   authors had available in HTML5" [1]
>
> Now ANY element can be used as a destination anchor in HTML5 (just  
> like HTML 4), using the id attribute.  Which means that the spec in  
> fact "continues to support <a> as a destination anchor."  Since any  
> element can be used so, it doesn't necessarily make sense to call  
> out the <a> element in particular as a destination anchor.  So I  
> don't really see what "valuable meaning" was removed.  The thing  
> that was removed was the ability to mark an <a> element as a  
> destination anchor in a fashion different from the way every other  
> element is marked as a destination anchor.  That's the part you say  
> you don't care about.
>
> What _do_ you care about?  Please forgive me is I assumed based on  
> the above that it was the name attribute.

You're honing in on what I was talking about now. There are reasons to  
have an element that says this is here solely as a anchor destination.  
A 'span' with an 'id' attribute might be there for some particular CSS  
hook. However, a phrase wrapped in an "a" with only an 'id' and no  
'href' is clearly an anchor destination. I think of this along the  
lines of other globalized attributes. Imagine a globalized 'cite'  
attribute as in XHTML2. The 'cite' on any element indicates the  
element's contents are attributed to—find authority in, or are  
credited to—the resource cited. However on the 'q' element that global  
'cite' attribute indicates that the attribution is a direct quotation  
of the cite resource. Or take the 'bdo' element as a similar example.  
There the global 'dir' attribute is used but on the 'bdo' element it  
has special semantics that stand out from the use of that global  
attribute on any other element.

Similarly any id can serve as a anchor destination, but an 'a' element  
with an 'id' alone is clearly an anchor destination. This is signaled  
to any other authors of the document in a way that a 'span' element  
with an 'id' attributes does not signal. Granted the processing norms  
are not effected as they are for 'bdo', but the semnatics conveyed to  
other authors and potentially users too are different. Is that a  
semantic worth adding if it didn't already exist? I'm not sure. Is it  
one worth removing for no apparent reason? I think definitely not. If  
there is a reason to remove that semantic for the 'a' element than it  
is something that should be discussed in the WG with an e-trail created.

>
>
>>> 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.
>
> It's not dropped.  Any element can be used as a destination  
> anchor...  I feel like I'm seriously missing something here.  Can  
> you tell what it might be?  :(

It is dropped from document conformance. The use of an 'a' element  
with only an 'id' attribute that is also relevant is not supported in  
the current HTML5 draft (but it has been supported in XHTML1.1,  
XHTML1, HTML 4.01, so why are we changing it?).


>>> 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.
>
> I'm not sure that follows.  Here's what the current draft has to say:
>
>  If the a element has an href attribute, then it represents a
>  hyperlink.
>
>  If the a element has no href attribute, then the element is a
>  placeholder for where a link might otherwise have been placed, if
>  it had been relevant.
>
> Is the argument that it should be possible to use <a> in situations  
> where you just want an anchor target that carries no other semantics  
> whatsoever past being an anchor target?

Yes. That has been supported in XHTML1.1, HTML4.01 and XHTML1. In fact  
that use of the anchor helps makes it clearer what it means to be an  
anchor (though XLink tends to use the term link in a synonymous way,  
collapsing the terms creates some ambiguity).

>>>> 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.
>
> Perhaps I misunderstood it one or both times, then.  This question  
> read to me like the "Does it make sense to change the special status  
> <a> has as a possible specially-called-out link target in HTML4?"   
> If that wasn't the question, was it the question above about using  
> <a> when you want an anchor target with no semantics?

Yes, but it can serve that purpose with an 'id' attribute just as well  
as it can with the since deprecated 'name' attribute.

>> 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.
>
> I agree that as an author if I tried to get guidance out of the  
> current spec I'd be pretty lost.
>
> Then again, that's where I was (and am, as an author) with HTML4 and  
> CSS2 as well...  In a number of cases, it's actually easier for me  
> to tell what some CSS will do by reading Gecko code than by reading  
> CSS 2.1.
>
> I think we all agree that we need a better document for author  
> guidance; there are several such documents in progress, including a  
> more author-friendly view of the full spec, right?

However, this WG (or someone) needs to produce a document conformance  
normative recommendation for a new HTML vocabulary that does make  
sense and serves as a reference for document authoring. That doesn't  
really need to be a part of the other implementation norms contained  
in the current HTML5 draft. Certainly a document conformance normative  
document would impact on some implementation norms, but they would be  
quite minor implementation norm changes (adding elements to parsing,  
perhaps some presentational norms and perhaps new events and  
interactive behavior in unusual circumstances). Other than those minor  
implementation norms, the thrust of the document conformance and the  
implementation conformance are very separate and divisible.

> In any case, it feels like we're getting closer to at least  
> understanding what the other is talking about.  Thank you for not  
> just giving up.

No problem. Thanks you too.

Take care,
Rob

Received on Thursday, 29 January 2009 23:44:53 UTC