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.

Received on Thursday, 29 January 2009 21:50:20 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:41 UTC