[spec] What to do of fragments when there is a redirection

Philip Linde linde.philip at gmail.com
Wed Dec 23 00:51:20 GMT 2020


On Tue, 22 Dec 2020 18:38:45 -0500
Sean Conner <sean at conman.org> wrote:

>   So here's a totally off-the-cuff spec I'm pulling out of my nether regions
> that seems simple and somewhat robust.

That's only good until the author of the document you link to modifies
it at an inconvenient place. It's only one step removed from defining
the fragment to be a byte offset.

It might be more robust to define the fragment as referring to the
first heading line that has the fragment content as a prefix, but
that's still prone to break with document changes.

In the most flexible of worlds, the fragment is a regular expression
that matches the line it refers to and an index to select one of
potentially many matching lines, but I don't quite like that idea.
There are too many subtly different regex implementations for it to be
practical, and it fundamentally doesn't solve the problem that
expectations will change with the text content of the document.

For a good balance, one might have the fragment be a an exact match of
the heading line you refer to, with simple wildcards like "*" for any
(or no) string of characters and "?" for any one character.

Here it seems that the separation of presentation and rendered content
in HTML is useful. You can change a heading or edit a document and
still refer to parts of it using a set of IDs that remain consistent
through the changes. Lacking that, perhaps one of these more or
less error prone solutions are OK for Gemini, but I tend to agree with
Petite Abeille that fragments should not have a special meaning for
text/gemini.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201223/48473551/attachment.sig>


More information about the Gemini mailing list