bug-texinfo
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: permanent links using #fragment names


From: Gavin Smith
Subject: Re: permanent links using #fragment names
Date: Sun, 9 Jan 2022 19:53:35 +0000
User-agent: Mutt/1.9.4 (2018-02-28)

On Sun, Jan 09, 2022 at 11:19:03AM -0800, Per Bothner wrote:
> > Can this be done without JavaScript or is it only for info.js?
> 
> If the manual is not split, then JavaScript would not be needed.
> Otherwise, JavaScript would be needed to resolve a fragment id
> to load the correct page.  However, one could generate in the ToC
> something like:
>   <li id="Keys">See <a href="Keys.html">Keys</a></li>
> That way, a link like "emacs#Key" would scroll to a link that
> the user could click.  If JavaScript is enabled, we could hide that
> link, or format it appropriately for the sidebar.

Redirection pages can be output using <meta> elements, without the
need for JavaScript:

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meta#attr-http-equiv

See for example

https://www.gnu.org/software/texinfo/manual/texinfo/html_node/indent.html

> However, there is an argument that ".html" is non-semantic
> implementation information that should not appear in putlic URLs.
> It is similar to a ".php" extension exposing implementation
> information.  That is why "emacs#Keys" is better than to "emacs/Keys.html".

It's certainly more elegant, but we are not generating documentation
to be served as part of some large information processing service,
like Wikipedia or other websites which don't use .html extensions.
We're generating a self-contained set of files that represent one
manual, in HTML.  These files could be accessed in a variety of ways,
not just as an online service.

In other words, the output from texi2any is small, self-contained and
inanimate.  The files should be output with .html extensions and link
to each other accordingly.

Any simplification of URL's should be treated carefully and be built
on top of the bare HTML layer if at all, not compromising the
functionality of this lower layer.


> We want URLs (the ones that are visible publicly or externally)
> to look the same whether it's an @anchor, a page-level @node
> (i.e. @chapter if splitting by section), or a sub-page-level @node (a 
> @subsection
> if splitting by section).
> 
> You can do that by making all public URLs have the form #NAME or all
> URLs have the form #NAME.html. The former is shorter, more elegant,
> more semantic - and doesn't hard-wire the use of html format.
> 
> If you use #NAME for your public URLs you'd like to automatically
> map that to the correct location in the correct file - without
> having to first load and parse all the pages. You avoid that
> by having the mapping from #NAME to location somewhere on the home page.

Okay, but if #NAME loaded a redirection page it could go to the right
place immediately.  The way you are thinking about it is that NAME is
passed to info.js which has to find where it is.  It all depends on
how the redirection pages are done.

Suppose you are already in a page in a manual, viewing it with info.js,
and you click on a link to an anchor.  Having that anchor on file could
be useful in that case - going via a redirection page could be a
jarring experience for the user, depending on how it is done.  I think
somebody would have to work out the details of implementing this and
we can go with whatever they worked out, if they made links to
anchors work better.



reply via email to

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