- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Thu, 29 Jan 2009 18:07:52 -0500
- To: Robert J Burns <rob@robburns.com>
- CC: HTML WG <public-html@w3.org>
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. >> 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? :( >> 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? >>> 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? > 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? 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. -Boris [1] http://lists.w3.org/Archives/Public/public-html/2009Jan/0578.html
Received on Thursday, 29 January 2009 23:08:39 UTC