Oh goodie. I thought I was the only one who'd run into this. But in my
case it's "despite" rather than "because of".
[spec]
The optional <base> element specifies the base address for resolving
relative links from the document, overriding any context otherwise known
to the user agent. The required HREF attribute specifies the RUI for
navigating the document (see 7, "Hyperlinks"). The alue of the HREF
attribute must be an absolute URI.
My interpretation is that the BASE url should be used by the browser
only for those other urls which are lacking a protocol and a hostname.
I had always assumed that the exception to this behaviour was urls in
the document which began with a # sign, which were always taken to
refer to the current document, regardless of the presence of a BASE
url. It follows that a BASE url should terminate with a directory
name, not a filename, and that relative urls in the document should
therefore begin with the relevant filename.
This had always worked for me until the penultimate version of Lynx,
which ignored BASE entirely, and failed to follow any relative
links. The current version fixes that, which must have been a bug.
The URL used here, though, points to an entirely different page -- one
which doesn't contain the named sections specified in the relative URLs.
I thought of revising my reading of this and say that if the author
includes a BASE url which _does_ end with a filename, then urls which
start with a # sign should be taken to refer to the file named in the
BASE. But that obviously won't jive, so I think someone who was in on
the start of BASE might let us know what the intention was.
In any case, your example seems to have a major flaw in that the BASE
url ends with a filename which is _repeated_ in many of the following
links. That just doesn't seem to make sense.
///Peter