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

Re: HTML is a declarative mark-up language

From: Leif Halvard Silli <lhs@malform.no>
Date: Mon, 02 Feb 2009 03:41:30 +0100
Message-ID: <49865D5A.2080506@malform.no>
To: Boris Zbarsky <bzbarsky@MIT.EDU>
CC: HTML WG <public-html@w3.org>

Boris Zbarsky 2009-02-01 04.21:
> Leif Halvard Silli wrote:

>   <p><a name="Anchoring_gear" id="Anchoring_gear"></a></p>
>   <h2>

> and that in fact the Wikipedia article is EXACTLY the kind of poor 
> authoring practice that the restrictions on the content model of <a> and 
> the belief that the anchor target must be an <a> has spawned.

Yes, the content model must have been the reason why they did not 
place <H2> inside <A>. We don't know why they picked <A> at all.

One functional benefit of their solution is it creates a margin 
between the <h2> header and the window top, when the anchor is 
activated. While the text of the H2 element will "bang its head" 
into the top of the window if you use <h2 id="Anchoring_gear"> 
instead. It requires a higher top-padding (and lower top-margin) 
to get the same result via CSS. Perhaps there is a cross-UA or 
other issue with that - I don't know.

>> When you look at the code, you are in no doubt of the purpose of that 
>> element there: it is solely there for the purpose of linking to it.
> Indeed, and in this case that's actually wrong from a semantic point of 
> view.  What's being linked to is not the empty inline inside the 
> otherwise-empty paragraph, but the section heading.  Things happen to 
> work with the page's default style because of the spatial proximity of 
> the two, but if a stylesheet positioned the section header and following 
> section, the link would go to the wrong place.  If the article were 
> paginated (e.g. in a projection medium) and the page break came between 
> the <p> and the <h2>, the link would go to the wrong place.

Yes. (Though paginating tools may keep elements together via CSS.)

But here is another usecase: What if I want to list all/most pages 
where a certain word occurs - in an index. Is there any better 
element than the anchor element if I want to create links in the 
index to each and every occurrance of a particular word? I could 
use <span>, of course. Span seems to be the universial cure ... 
But it would easily be much simpler to just use <A>. E.g. I could 
use it to avoid mixing it up with other purposes that I might use 
SPAN for.

Further more, a more fundamental question - more related to the 
general usecases rather than Wikipedia: Why should it be 
considered more legitimate to /not/ add a phrasing element around 
the hypertext link source anchor, than around the destination 
anchor? If the source anchor doesn't need it, why should the 
destination anchor?

> I do appreciate you finding such an excellent example in the wild, on a 
> quite popular site run by people who generally know their HTML, of the 
> exact problem I described.

Would be interesting to know more about Wikipedia's exact problem.

>> Also, if I want a place to be a destination anchor, without having  to 
>> investigate or find out (it may be impossible to know the content of 
>> the A element if it is generated via DOM etc) the *further* semantics 
>> of the anchored resource, then I can use <a id="ref">resource</a> and 
>> be certain that I have at least not lied plus that I solved a 
>> practical problem.
> I'm not sure I follow this use case.  Would you be able to give a 
> concrete example?

Let's say I meant something like what Wikipedia could do, in HTML 
5: ;-)

<a id="placeholder"><h2 id="something_or_nothing" >text</h2></a>

>> I cannot really agree that HTML 4 gives a privileged status to the A 
>> element. [...]
> Sure it does. [...]

Ok. I give you right. I over-defended it ... ;-)

> The result is that far too many people end up with the impression that 
> the <a> element is the only way to create a link target.

I think we agree that we cannot use Wikipedia as proof for that. 
They probably have some other readon - good or bad. Hence, it 
would be interesting to know whether you are right, based upon 
some kind of study. I think that a newbeginnner could perhaps 
easiily make that conclusion. However, not by *reading* HTML 4, 
because HTML 4 explains about both <a name> and @id in general 
when it explains the desetination anchor concept.

But another reason for this (eventually) happening is that A is 
the only way to create links, as well. If any element could be a 
link by the adding of href, then it would also be easier to grasp 
that neither does destination anchors need to be A elements.

>> However, if I have gotten it right, in HTML 5 it will be 
>> non-conforming to e.g. write
>> <body><inline-elemetn></inline-element></body>
>> (or has that idea been left?)
> I have no idea, honestly.  What does that question have to do with the 
> discussion at hand?

You mentioned that a "loose" <a id=ref></a> could easily float 
away from the target it was placed beside, e.g. due to CSS float 
or something. E.g. in this example:

<div><a id=ref></a><table ... /table></div>

I just thought that if "loose" inline elements like in the example 
above (and I guess A would be inline here) was nonconforming, then 
we would see less of it. For instance, in the Wikipedia example 
above, they placed it inside the P-element no doubt because then 
it would not "float a way" very easily (even if for sure is 
possible that it could).

In short: to place an <a> inside a <P, or <Hn> element is one 
thing. To just drop it inside the <body> is another thing.

>> How would you take away the special status, I wonder ... After all, it 
>> only has two purposes - anchored link or link anchor.
> You could say that an <a> with an href is a link, while an <a> with no 
> href is semantically equivalent to a <span>, for example.

Well, ok, in short I hope we do not say that - see reasons above. 
I think also first we must establish that it is indeed "misused" 
and eventually why. And I don't know if preferring <a> over <span> 
could generally be considered misuse ...
leif halvard silli
Received on Monday, 2 February 2009 02:42:12 UTC

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