W3C home > Mailing lists > Public > public-html@w3.org > June 2008

Re: improved HTML fragment identifiers

From: Erik Wilde <dret@berkeley.edu>
Date: Mon, 09 Jun 2008 15:07:15 -0700
Message-ID: <484DA993.1070504@berkeley.edu>
To: public-html@w3.org
CC: Anne van Kesteren <annevk@opera.com>

hello anne.

thanks for your response.

> To me it seems like a solution looking for a problem. If I want to point 
> someone to a quote in a document I typically extract the quote (copy and 
> paste) and hand that over plus the URL so they can figure out the 
> context (using inline find or manual scanning). This works quite well 
> and even has the advantage that you don't necessarily need to retrieve 
> the resource.

that's what everybody has to do because of a lack of a better way of 
doing it. using fragment identifiers certainly has a certain aura of 
doing something obscure, but i think it is the better way of pointing to 
something. if you extract, you loose context and people have to 
re-establish context by searching. if you point to a fragment, people 
can look at the content directly within its context.

this of course depends on tool support, the usual chicken-and-egg 
situation. i think html5 would be in a good position to lay a really 
good egg here ;-) but i am sure there are many more people with the 
"solution without a problem" attitude. i guess my main motivation is 
that my personal background is in document processing and hypertext, and 
i always like ideas that try to turn the web into a better hypertext system.

> Besides that, apart from dated W3C TR/ URLs resources on the Web 
> frequently change so a simple pointer to the third paragraph in a 
> document becomes very ambigious over time. (To be fair, this is also 
> true to a certain extent for URLs and the fragment identifiers we have 
> today, but less so, I think.)

yes. all pointers on the web are transient (unless the URI provider has 
a very strict persistence policy), and fragment identifiers certainly 
more so than plain URIs. but i don't think this is an argument against 
the proposal, it is a general observation of the nature of the web.


Received on Monday, 9 June 2008 22:08:30 UTC

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