Re: HTML is a declarative mark-up language

Robert J Burns 2009-01-30 00.44:
> On Jan 29, 2009, at 5:07 PM, Boris Zbarsky wrote:
>> Robert J Burns wrote:

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

He also complained that <a> deosn't mean 'anchor' anymore. And 
that was the thing that fastened in my head when I read it, and 
which I took up. (I was so geared to that side of his response, 
that it surprised me to see all the reactions regarding "name".)

> 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 

Good analogy.

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

HTML 4 doesn't discuss only <a> when it talks about anchors. E.g. 
it says: "Destination anchors in HTML documents may be specified 
either by the A element (naming it with the name attribute), or by 
any other element (naming with the id attribute).". Thus it is as 
if HTML 4 did not specificly think about using the A element with 
only the ID attribte but without the name attribute.

Perhaps the biggest loss with regard to this subject in HTML 5 
(sofar) is that it doesn't use the *concept* of anchors. E.g. 
chapter 12.1 of HTML 4 is called "Introduction to links and anchors".

Side note:  It would have been in line with the HTML 4 
generalisation of the "destination anchor" concept (to cover any 
element with an id attribtue), to likewise make any element with 
the href attribute a link, the way XHTML 2 does.

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

Rob, I don't understand why you say that this example would not be 
conforming in HTML 5. Example:

	<a id="instead_Of_Name_Attribute" >
		Link to me
	</a>

True, the spec says that "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."  But unless I get to 
hear such an intepretation from an authorative source, I cannot 
imagine that this could be non-conforming? And it sounds as if 
Boris is of the same view. The A element cannot be the single 
element where the use if the id attribute is considered 
non-conforming, unless there is a href attribute as well?

That said, and in line with the special role of the anchor 
element, it would of course been meaningful if the draft also had 
explained that the A elemnet could be used as a link destination 
anchor, instead of limiting its role to only be a link source anchor.

Yes, and it would be the more relevant to make this point about A 
as *also* a destination anchor if the name attribute is dropped, 
so as to explain that no *semantical* functionality is lost - one 
can still use <a id="idref"> for the same purpose.

(I don't know if there are any UAs in use today that *require* A 
with name instead of any element with the id attribute. But I 
guess Wikipedia could be an interesting place to ask the question ...)

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

Good point. Though in HTML 4 the anchor element has that name not 
only becase it can represent a destination anchor, but because it 
is the spesific element for anchoring links within the BODY element.

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

Indeed.

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

I realise that I perhaps am not familiar with the way you (both of 
you - perhaps) use "semantics".

HTML 5 doesn't mention that one can use <a> with only a id 
attribute. But that to me seems mostly like an oversight - which, 
btw, no doubt stems from the fact that the draft isn't sticking to 
the meaning of the "a", namely anchor, but instead talks about it 
as "link" in the belief that there is nothing useful in the 
traditional terminology.

Anchor or link anchor is a more precise term, simply put.


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

Agree.
-- 
leif halvard silli

Received on Friday, 30 January 2009 03:23:38 UTC