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.) "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:) I suggest an option (perhaps the default) to always prefer the #hash form. So the public link might be: 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. 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. 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. -- --Per Bothner p...@bothner.com http://per.bothner.com/
