W3C home > Mailing lists > Public > www-talk@w3.org > January to February 2002

Re: Searchable Reader-side URL Anchors ...

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Wed, 20 Feb 2002 19:10:44 +0100
To: Mirsad Todorovac <mtodorov@alu.hr>
Cc: <www-talk@w3.org>
Message-ID: <nm657uolraf1t44ae2sugirkrs98icbirs@4ax.com>
* Mirsad Todorovac wrote:
>For example, I refer to http://{...}/rfc1738.txt, second chapter, third
>paragraph - the cute way to do it would be to have browser immediatelly
>open desired chapter and paragraph; without forcing user to scroll and
>find it.
>
>Back then I proposed syntax for new type of URL with new type of anchor:
>
>	http://{...}/.../.../rfc1738.txt##Second%20Chapter
>
>... to distinguish it from #Second%20Chapter, which would in turn refer to
>a <A NAME="Second Chapter"> in HTML file (but in plaintext, as you have
>already spotted - there are no anchors).

"Second Chapter" would not be a valid HTML anchor identifier... However,
this is a problem of the media type, not of the URI. You can define what
fragment identifiers refer to in text/plain documents, this would only
require an RFC that updates the original text/plain registration, but I
doubt this would make sense. How would an application determine where
your fragment "#Second Chapter" is in that plain text file? How would
you define this in a generic way, even with your ## syntax?

>You must remember many situations when you were refered third chapter in
>larger page, but have been diverted your attention in first or second
>chapter and started to red that, forgetting what you came for in the first
>place?

What about the simple conclusion that it is a bad idea to publish larger
documents in text/plain?
Received on Wednesday, 20 February 2002 13:12:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 October 2010 18:14:27 GMT