bug-texinfo
[Top][All Lists]
Advanced

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

Identifying links to other Texinfo manuals in HTML


From: Gavin Smith
Subject: Identifying links to other Texinfo manuals in HTML
Date: Sun, 18 Oct 2020 22:48:14 +0100
User-agent: Mutt/1.9.4 (2018-02-28)

Does anybody have a good idea how links to other Texinfo
manuals could be marked in the HTML output?  At present
there is nothing to distinguish a link like

<a 
href="https://www.gnu.org/software/emacs/manual/html_mono/elisp.html#Special-Forms";>Special
 Forms</a>

from a link like

<a href="http://ctan.org/pkg/cm-super";>CM-Super</a>

This would be useful for a local documentation browser to try to look
up the link on local storage first before going to the actual URL.

I imagine it would be done with the "rel" attribute.  However,
I couldn't find an appropriate standard value for it:

https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel

I also looked at this page:

https://microformats.org/wiki/existing-rel-values

The only one I could see there which was remotely relevant was
"collection" that wasn't even used with HTML.  ("Refers to a resource
which represents a collection of which the current resource is
a member.")  The totality of all Texinfo manuals is not really a
"collection".

Hence I'd propose using a new value for "rel": "rel='path'" maybe
to say that the file could be looked up in a search path?  Any better
ideas?

This is assuming that the "rel" value would even be accessible to
the code in the browser.  Looking at the WebKitGTK documentation,
there doesn't seem to be an easy way to get it: e.g. the "send-request"
signal allows you to get the URL, but not the element for the link
that has been clicked on:

https://webkitgtk.org/reference/webkit2gtk/stable/WebKitWebPage.html#WebKitWebPage-send-request
  
Probably something could be worked out with injected JavaScript if
really necessary.

The alternative is changing generation of locally installed HTML
manuals to change the URLs of links between manuals to something
recognizable.  For example, using relative names (starting "../") would
lead to a "file:" URL being seen by the signal handler.  The problem
with this approach would be persuading package maintainers to change
the way they generate documentation.  Moreover, the "canonical"
web URL would be lost from the file.



reply via email to

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