- From: Patrick H Lauke <splintered@gmail.com>
- Date: Fri, 30 Jan 2009 22:51:24 +0000
- 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 http://webstandards.org/ 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