Re: using hashes for internal URLs

[Patrice Dumas]

On Thu, Dec 15, 2022 at 02:32:12PM -0800, Per Bothner wrote:
> When using the js-info reader, the location bar displays these URLs for nodes:
>   https://domterm.org/Wire-byte-protocol.html (if http/https)
>   file:///home/bothner/DomTerm/web/index.html#Wire-byte-protocol (if file:)
> These are also what you get if you right-click a link and select "Copy link".
> 
> (The reason for the difference if using file: scheme has to do with browser
> security restrictions.)

I am probably missing something, but to me the difference seems to be
between split by node and monolithic?

> "Inner" URL have the form:
>   https://domterm.org/Wire-byte-protocol.html#Window-operations (if 
> http:/https:)
>   
> file:///home/bothner/DomTerm/web/index.html#Wire-byte-protocol.Window-operations
>  (if file:)

The second does not looks like something generated by texi2any.  Is
there some remapping done by javascript?

> I suggest an option (perhaps the default) to always prefer the #hash form.
> So the public link might be:

Not sure that it is what you are looking for, but the first can already
be achieved for links going towards the manual by having the following
entry in htmlxref.cnf:

domterm mono https://domterm.org

>   https://domterm.org#Wire-byte-protocol
> Most servers would treat the following as equivalent to the above:
>   https://domterm.org/#Wire-byte-protocol
>   https://domterm.org/index.html#Wire-byte-protocol
> 
> So far this makes for slightly shorter URLs, as well as consistency
> when using file: URL. The big win comes if we do the same for
> inner URLs.  So the Window-operations link becomes:
>   https://domterm.org#Window-operations
> 
> This requires a mapping table generated by tex2any so info.js can
> translate #Window-operations to Wire-byte-protocol.html#Window-operations.
> This table should include *all* @node names *and* @anchor names.

I may be off, but to me it looks like this is very similar to what is
described in:
 
https://www.gnu.org/software/texinfo/manual/texinfo/html_node/HTML-Xref-Mismatch.html
except that the manual name is used instead of index.html or even
nothing as in https://domterm.org#Wire-byte-protocol.

> This would allow links to remain valid even if things are moved
> around. I think this makes for a nicer solution than using
> redirection pages.

The redirection pages are for a similar issue the other way around, it
is when there is a need to link to a non split manual.  So I am not sure
that it could be an alternative.  Or maybe you suggest always assuming
that the manual is non split and use javascript to redirect?

> To handle the case when JavaScript is missing/disabled, we can
> make the re-mapping table human-readable. Perhaps:
> 
> <li id="Window-operations"><p>
> For ``Window operations'' see <a 
> href="Wire-byte-protocol.html#Window-operations">here</a>.
> </p></li>
> 
> Then using the URL with the hash #Window-operations takes to a line
> with an easy-to-click link to the correct file and position.
> The re-mapping table would be hidden if using JavaScript.

I do not like something like that requiring to click manually if there
is no javascropt in the default case.  But it could be an additional
way to get to the nodes locations, and/or something triggerd by loading
an init file/setting a customization variable.


Even though I did not understand everything well, if you could tell me 
a bit more precisely where/in which format you want the table you
proposed above to be setup, I could propose an init file which generates
it.

-- 
Pat