Re: HTML is a declarative mark-up language

Leif Halvard Silli wrote:
> Boris Zbarsky 2009-02-01 04.21:
>> 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.

While this last is true, I will lay odds that my above characterization 
is correct.  Given the source, it's also possible they were aiming for 
maximum cross-browser compatibility, including browsers that don't 
implement the linking-to-id part of HTML4, of course.  I'm not sure we 
should be letting such browsers dictate HTML5.

> 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.

I just tested this in Opera, Safari, and Firefox.  Only Opera has the 
behavior you described.  In the other two, the point scrolled to is the 
same whether the id is on the <h2> or on the <a>.

Opera's behavior is due to either a bug in margin collapsing or possibly 
different values for the margins (e.g. if the bottom margin of the <p> 
in Opera is bigger than the top margin of the <h2>).

In all three cases, though, the result looks significantly better when 
scrolling directly to the <h2>, at least over here.

> 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 don't think so, no.

> 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.

OK, I almost buy this.  How about saying that <a> without @href is a 
link destination in text and should be used in cases when one wishes to 
link to a particular piece of text that is not otherwise marked up 
already.  Then we can make <a> without @href and without children 
non-conforming.  Further, we can make <a> without @href that has no 
leading or trailing non-whitespace text children nonconforming, right?

> 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?

Right.  In other words, if you're linking to text, not to an element, 
how should it work?  I think the above proposa covers that case.

>> 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.

Agreed.  Unfortunately I have no contacts at wikipedia, and some digging 
didn't locate any sort of revision history for the exact mechanism that 
transforms "== foo ==" into an <a> and <h2>.  If someone happens to have 
any such contacts or knows where said revision history can be found, I 
would much appreciate that.

>>> 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>

Why is that desirable, though?  Either as something one might want to do 
or as something one should be allowed to do?


>> 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

While it's not "proof", I think it's pretty strong evidence for it...

> They probably have some other readon - good or bad.

I doubt that, actually.  Again, having hard data would be nice.

 > 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.

I've read HTML4 a few times, and I still forgot that you can target 
random IDs in HTML4.

And yes, most beginners don't read HTML4.  They read tutorials or 
copy/paste.  Very few tutorials mention linking to IDs.

On the other hand, if validators flagged situations like this and 
suggested linking to an ID, that would be a big step up, in my opinion.

>>> 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. 

Right.

> 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.

I don't see what that has to do with the issue at hand, though.  In your 
example, if the <a> were in a <p> and the table were floated, the table 
could end up nowhere near the <a>.

In fact, the CSS box models for <a> inside <p> inside <div> and <a> 
directly inside <div> are basically identical, modulo the margins on the 
<p>.  Runs of inline kids inside a block are conceptually wrapped into a 
single block box.

I doubt that any of this had to do with the reasoning on the Wikipedia 
template.

-Boris

Received on Monday, 2 February 2009 03:41:53 UTC