It was intended to be very easy to implement, and to fit into currently
used scheme (to avoid breaking existing documents and browsers). Apparently,
the anchors which start with '#' are the only one which would be affected, if
anyone uses them. They are also thought of as intuitive :
o ##123 is like # after which follows #123
o ##/abc is like ## after which comes /abc, which you can use to search
string in wide range of programs and languages, like sed,
awk and perl etc. So, it's not so ad hoc, it here for some 20
years or so. The #/abc could be used where there is no /abc
<a name="/abc"> in document being pointed to.
> > 6. If there are browser or server implimentor looking to
> > add "selection" anchors we should define the
> > conventions. Most current browsers, as far as I know, do
> > not send the #anchorName in the HTTP GET or POST and will
> > not, therefor, work as is with selection anchors.
>
> That's good -- they should never be set to the server. Although
> the URI spec is not fully clear on this point, I would strongly
> object to muddying the current stable distinction between "?" as a
> server-side resource specializer, and "#" as a client-side resource
> specializer.
>
> Netscape is also proposing to make use of URL paramters (";" stuff)
> for server-side byte-range extraction, which seems like a good
> idea.
Something on the server side ought to be done. I'm not sure how many WWW
authors will be delighted to count bytes up to the part of the document they
want to address, but it's better than nothing. -- Mirsad