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

Re: HTML is a declarative mark-up language

From: Patrick H Lauke <splintered@gmail.com>
Date: Fri, 30 Jan 2009 22:51:24 +0000
Message-Id: <D9CB6341-07B2-46B3-BD55-2CB5443DECCD@gmail.com>
To: Robert J Burns <rob@robburns.com>
Cc: Boris Zbarsky <bzbarsky@MIT.EDU>, HTML WG <public-html@w3.org>

apologies for iphone's top-posting...

just picking up on the example of the important phrase, would it then  
not be appropriate to mark the importance with a <strong> element,  
which then gets an @id ?

Patrick H. Lauke
re.dux (adj.): brought back; returned. used postpositively
[latin : re-, re- + dux, leader; see duke.]

www.splintered.co.uk | www.photographia.co.uk

Co-lead, Web Standards Project (WaSP) Accessibility Task Force

On 30 Jan 2009, at 22:25, Robert J Burns <rob@robburns.com> wrote:

> 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:57:13 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:42 UTC