W3C home > Mailing lists > Public > public-html@w3.org > January 2009

Re: HTML is a declarative mark-up language

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Thu, 29 Jan 2009 16:48:26 -0500
Message-ID: <4982242A.3020608@mit.edu>
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

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:00 UTC