Re: Identifying links to other Texinfo manuals in HTML

[Patrice Dumas]

On Sun, Oct 18, 2020 at 10:48:14PM +0100, Gavin Smith wrote:
> Does anybody have a good idea how links to other Texinfo
> manuals could be marked in the HTML output?  At present

I would suggest not using rel, I think that rel should only be used when
there is an obvious interpretation for it in the standard.  But even in
that case, the meaning are often subjective.  And between HTML standard
iterations rel could change.

I would suggest instead using the class attribute.  That way it could
also be used to have different css style defined by a use for links to
manuals.  It would even be possible to have a different class for
internal and external links.

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