Re: HTML is a declarative mark-up language

Hi Boris,

On Jan 30, 2009, at 3:32 PM, Boris Zbarsky wrote:

>
> Robert J Burns wrote:
>> You're honing in on what I was talking about now. There are reasons  
>> to have an element that says this is here solely as a anchor  
>> destination. A 'span' with an 'id' attribute might be there for  
>> some particular CSS hook. However, a phrase wrapped in an "a" with  
>> only an 'id' and no 'href' is clearly an anchor destination.
>
> I guess I'm at a bit of a loss to think of a situation where  
> something is solely an anchor destination without having any other  
> semantics. Anything I can think of linking to directly as part of a  
> document (sections, images, lists, tables, <pre> blocks with program  
> code, quotations, etc) all have appropriate semantic tags that one  
> would need around the thing being linked to anyway...  At that  
> point, it might be more clear to put an ID on said semantic tag and  
> use that as the anchor destination.
>
> Maybe there are situations I'm just failing to think of here?

The situation I'm mainly thinking about is the one I've raised before.  
An author has a phrase that the author wants to serve as an anchor  
destination. There is no other reason the author would markup the  
phrase except because it needs to serve as an anchor destination. The  
approaches I compared before was either:

<p>A paragraph with  <a id='anid' >a very important phrase</a> cited  
elsewhere in other documents.</p>
<p>A paragraph with  <span id='anid' >a very important phrase</span>  
cited elsewhere in other documents.</p>

In the first case the use of the anchor element clearly conveys that  
the contents are needed as an anchor destination. In the second case  
an author (for example a subsequent author) would need to have access  
to the entire public and private computer network to determine that  
this is not needed anymore. The second example might be used to style  
the contents or otherwise make the element content available in some  
non-link/non-anchor way. The first case more clearly conveys that this  
fragment is participating in a link (again something particularly hard  
to determine otherwise due to the usual approach where all of the  
information about a link goes in the source anchor/link).

>> Similarly any id can serve as a anchor destination, but an 'a'  
>> element with an 'id' alone is clearly an anchor destination. This  
>> is signaled to any other authors of the document in a way that a  
>> 'span' element with an 'id' attributes does not signal.
>
> While true, it also leads to this fairly common HTML4 authoring  
> pattern (with name replaced by id on the <a>):
>
>  <a id="mytable"></a>
>  <table><tr><td>
>    This is an important table that people should link to
>  </td></tr></table>
>
> both because authors copy/paste from existing HTML (which is  
> informed by the HTML 3.2 legacy of not being able to link to IDs)  
> and because the spec gives <a> a privileged status as an anchor  
> destination that obscures the fact that any element can be an anchor  
> destination if that's what you're really meaning to link to.
>
> Note that the above example would break badly if someone happens to  
> apply a style that positions the table away from the anchor.  So  
> it's not just a matter of semantic purity being violated (thought it  
> most certainly is), but of practical consequences that make the  
> document less robust than it could be.

I'm not sure what that has to do with the present conversation.  
Obviously this is a pattern we need to support in implementation  
conformance due to legacy content. However, the present conversation  
is about whether we should allow authors to continue to use <a> in  
HTML5 document conformance, so I'm not sure what this example has to  
do with that topic. To address the issue you raise in terms of  
document conformance, I would think we should say this is a deprecated  
usage of the <a> element in HTML5 that instead the author should wrap  
the table in the <a> element use the id attribute on the table itself  
(if the author deemed the anchor as unnecessary).

>> It is dropped from document conformance. The use of an 'a' element  
>> with only an 'id' attribute that is also relevant is not supported  
>> in the current HTML5 draft (but it has been supported in XHTML1.1,  
>> XHTML1, HTML 4.01, so why are we changing it?).
>
> I agree that this is a good question.  It seems to me that while the  
> use of such an <a> should be conformant, it should be given no  
> special status as an anchor destination, for the above-described  
> reasons.

I'm not following your logic. What are the above-described reasons  
that would make <a id='anid' >an anchor destination</a> a bad idea for  
document conformance.

>> However, this WG (or someone) needs to produce a document  
>> conformance normative recommendation for a new HTML vocabulary that  
>> does make sense and serves as a reference for document authoring.
>
> Agreed.
>
>> Certainly a document conformance normative document would impact on  
>> some implementation norms
>
> Sadly also vice versa in some cases...  The meaning of some elements  
> is very difficult to describe, much less understand, without  
> reference to the processing model...

Not in terms of normative language however. It helps authors to  
understand document conformance norms by informatively notifying them  
of presentation examples, however, can you come up with an example  
where the authors need to be told specific implementation norms to  
understand the document conformance norms.

Take are,
Rob

Received on Friday, 30 January 2009 22:26:02 UTC