Re: link handling in js-reader

[Gavin Smith]

On Wed, Mar 03, 2021 at 08:09:01AM -0800, Per Bothner wrote:
> The JavaScript info reader calls the fix_links function to convert
> cross-references to special "magic" links that load a different page
> (or scroll within the current one). "External" references are unchanged,
> except the 'target' attribute is set so they open in a new tab.
> 
> This logic is rather broken in the case of relative URLs.  You can see
> one place where a link is treated as internal but should be treated as 
> external:
> https://per.bothner.com/tmp/DomTerm-txjs-plain/index.html
> Click on the first image.

Is this problem just for links to images?  Are there other "internal"
links that could have this problem?

Was the link to the image generated with @uref or was it just created
with @image?  If it's the former, perhaps there should be some way of
linking images automatically for HTML output (maybe work to be done for
the future).

> Ideally, one could determine which links are internal by checking for an
> entry in the table-of-contents.  However, that is bit complicated,
> mainly because sub-pages don't have access to the ToC, so it would
> have to involve message sending between JavaScript contexts (no big deal).

It's up to you but it would probably be better to avoid this if possible,
as the architecture of the system is already slightly tricky.

> Alternatively, we can have makeinfo mark external and internal references
> differently, perhaps by setting a 'target' attribute for @uref.

I don't think any change to @uref is needed.  A change to the HTML output
to use different attributes might be possible but doesn't seem necessary
at this point.

> Or we can use better heuristics: Only treat as internal references ones
> that are in the same directory (no '/' in the URL) *and* whose
> extension is either '.html' or '.xhtml' (for future xhtml/epub support)
> - e.g.. images are "external".  Or maybe require the file extension in
> the link to match that of the current page for it to be considered internal.
> 
> I'm leaning towards the latter approach, which would only
> require a modest change to fix_links.

If it's a simple fix then that sounds good.  .htm could be another extension.

Another idea is to exclude links to images, but then you would have to have
a list of image file extensions, which is not as good.

> Comments?
> -- 
>       --Per Bothner
> per@bothner.com   http://per.bothner.com/
>