bug-texinfo
[Top][All Lists]
Advanced

[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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]