Re: "placeholder link"

At 09:19 +1000 UTC, on 2007-06-25, Lachlan Hunt wrote:

> Sander Tekelenburg wrote:
>> Btw, the relevant section,
>> doesn't seem to define "placeholder link"; doesn't define what the UA should
>> do with it. Surely it should define that UAs should present such content as
>> if there is no <a> element present? It would suck for users if such a 'link'
>> would be presented as if it is a hyperlink.
> That will be addressed in the rendering section, which hasn't been
> written yet.

OK. (You mean


> The extra a element is often useful as an
> extra hook for styling in practice.

I don't see how that's a valid argument. Surely we already have span for that?

But if this abuse of <a> is in fact found in the wild a lot I can understand
it makes sense for HTML5 to define how UAs should treat it. If "styling hook"
is its function, than let's have the spec define that UAs must treat <a> as
<span>. <a>content</a> must not be presented as a link in UAs' default style
sheets. (There you have it: I now see the argument for HTML5 defining a
default style sheet ;))

Even then, defining how UAs should handle the situation is one thing,
declaring such a document conforming is another. So why exactly should
<a>content</a> be defined as conforming?

Remember that not only UAs consume HTML. People do as well. Imagine getting
handed down a site to maintain, and having to deal with crap markup like
that. You start fixing the markip and suddely the  presentation is all
screwed up because the CSS expected crap. Yet you can't complain to your
boss, because your predecessor ensured the document is conforming.

Allowing this sort of thing may in fact well make it harder to make good
authoring tools. Imagine one authoring tool spits out perfectly HTML5
conforming <a>content</a> and then you move to another perfectly HTML5
conforming authoring tool, that cleans up the markup, changing <a>content</a>
to <span>content</span>. The accompanying CSS/javascript would lose its hook,
and the site's suddenly a mess. That second tool would lose customers.
Therefore, it simply won't offer such a cleaning function. And yet we should
want such tools to contain such functions, because the cleaner the HTML they
produce, the easier that HTML will be to read/understand by humans and thus
the smaller the chance that authors will make mistakes.

Sander Tekelenburg
The Web Repair Initiative: <>

Received on Monday, 25 June 2007 03:55:34 UTC