[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bad relative urls in texinfo-4.0f
|
From: |
Eli Zaretskii |
|
Subject: |
Re: bad relative urls in texinfo-4.0f |
|
Date: |
Thu, 31 Jan 2002 10:58:16 +0200 (IST) |
On Thu, 31 Jan 2002, Per Bothner wrote:
> > Can you tell why ``ugly''? Those links are never displayed to the user,
>
> They *are* displayed to the user, at least in the URL bar of Mozilla.
In the URL bar, yes. But this also happens with many other documents:
e.g., go to http://www.gnu.org/software/software.html, click
on "How To Get GNU Software", and you will see this in the URL bar:
http://www.gnu.org/software/software.html#HowToGetSoftware
> > And they are not redundant, even when there's only one node per file: the
> > file does not begin with the node text, so the direct link to the anchor
> > makes sure you land on the text, not on the preamble.
>
> This seems like questionable UI design.
I didn't design HTML, I just work here ;-)
You could have an HTML document that has free text before the actual
node. HTML only promises that you will end up on the first line of text
after <body>. Having a link gets you to the right place with 100%
certainty.
Anyway, this is not an important consideration, although it does help in
a few cases. The most important one is the need to support several nodes
on a single file.
> > One problem this
> > fixes are the references to the Top node (which is on the same file as
> > the TOC):
>
> Well, in my kawa.texi, the toc follows the contents of the Top node,
> and I see no reason you'd want #Top.
I'm not sure I follow. Top is not the TOC, it's a different part of the
document. When a user requests Top, she should land where she wants.
> Actually, I don't think we need to care whether a node is alone in a
> file, only whether it is the "top-most" node in a file. This we could
> know in advance.
You know that when you process the @node line, but not when you process
the @xref command. Especially if it's a forward reference, let alone a
reference to another document (which might not even exist yet). This is
_the_ most important reason for adding those anchors. I don't see any
way to solve this complication without having the anchors.
> > We could probably make another pass after everything is
> > finished, and remove those anchors from links to files that have only one
> > node, but is the problem really worth the slow-down and complexity of
> > another pass?
>
> Who cares about slow-down?
I do.
> > Is the ugliness of the %20 thing the only problem, or are there others?
>
> Note the %20 thing - the entire #Node thing - which *is* user visible.
As I mentioned above, you see these #Foo things in lots of HTML
documents. It's not that Texinfo is the only one.
Anyway, this was done out of necessity--I think useful and stable
functionality comes before marginal aesthetics. Before v4.0f, split-HTML
output mode simply didn't work well enough to be useful. I didn't see
any reasonable way of fixing that without adding those anchors into the
URLs. If there's a way that avoids them, I'll be happy to hear about it.