- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Thu, 29 Jan 2009 16:48:26 -0500
- To: Robert J Burns <rob@robburns.com>, HTML WG <public-html@w3.org>
Robert J Burns wrote: > As usual, Boris, you're unable to listen to what others are saying. If that were the case, I wouldn't be bothering to reply to this at all. > 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 and allowing people to put html inside that in a foreignobject. > 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're asking here. > 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 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 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? > 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. > 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 one that I agreed is worth answering before in this thread. The tradeoff seems to be a more complex model (where targetable things come in two flavors) vs better compatibility with UAs that do not implement targeting ids (are there many of these?) and better mind-compatibility with HTML4. It's not clear to me where the tradeoffs lie here. > 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. > 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). I don't think anyone's leaving anything to Ian's whims. I think HTML4 semantics are often woefully underdefined and Ian has said as much. That's not the same as "doesn't understand the semantics", it's "they're so vague there's nothing to understand." I think Ian does in fact care about people's views. He may not agree with them. He may not always change the draft to conform to them. But he does care. -Boris
Received on Thursday, 29 January 2009 21:50:20 UTC