💾 Archived View for gemi.dev › gemini-mailing-list › 000195.gmi captured on 2024-06-16 at 12:48:49. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
"A client SHOULD NOT send the fragment part of a URL to the server." -- Sean Conner, Resource request format for Gemini' states, circa 2019-08-01 https://portal.mozz.us/gemini/gemini.conman.org/gRFC/0002 Such restriction is not reflected in the spec itself. At the same time, the spec mentions header lines as "machine-readable representation of the internal structure of the document". Could one reflect such structure using fragments? E.g.: gemini://gemini.circumlunar.space/docs/specification.gm#5.4+Core+line+types Part of the gemini canon?
On Tue, Jun 09, 2020 at 09:46:56PM +0200, Petite Abeille wrote: > "A client SHOULD NOT send the fragment part of a URL to the server." > -- Sean Conner, Resource request format for Gemini' states, circa 2019-08-01 > https://portal.mozz.us/gemini/gemini.conman.org/gRFC/0002 > > Such restriction is not reflected in the spec itself. > > At the same time, the spec mentions header lines as "machine-readable representation of the internal structure of the document". > > Could one reflect such structure using fragments? > > E.g.: > > gemini://gemini.circumlunar.space/docs/specification.gm#5.4+Core+line+types > > Part of the gemini canon? It's certainly something people have suggested. I guess to make it work reliably would require a very strict specification of how to transform headings into fragments, which sounds fiddly and dull... Either that, or we allow just numeric fragments like 3.2, which the client is supposed to map to the second subsection of the third section. Sounds like a pain to implement in terminal clients, at least. Cheers, Solderpunk
On Tue, 9 Jun 2020 21:46:56 +0200 Petite Abeille <petite.abeille at gmail.com> wrote: > gemini://gemini.circumlunar.space/docs/specification.gm#5.4+Core+line > +types > > Part of the gemini canon? Why send the #5.4+Core+line+types part at all? Can't a client send the URL without the anchor tag, and then use the anchor tag to automatically scroll to the specified heading? -- Matthew Graybosch https://www.matthewgraybosch.com #include <disclaimer.h> gemini://starbreaker.org Harrisburg,PA gemini://demifiend.org "Out of order?! Even in the future nothing works."
On Tue, Jun 09, 2020 at 04:02:57PM -0400, Matthew Graybosch wrote: > On Tue, 9 Jun 2020 21:46:56 +0200 > Petite Abeille <petite.abeille at gmail.com> wrote: > > > gemini://gemini.circumlunar.space/docs/specification.gm#5.4+Core+line > > +types > > > > Part of the gemini canon? > > Why send the #5.4+Core+line+types part at all? Can't a client send the > URL without the anchor tag, and then use the anchor tag to automatically > scroll to the specified heading? Oh, sure, no need to send it to the server. Sorry, I missed the that was what Sean was originally talking about. Cheers, Solderpunk
> On Jun 9, 2020, at 22:02, Matthew Graybosch <hello at matthewgraybosch.com> wrote: > >> gemini://gemini.circumlunar.space/docs/specification.gm#5.4+Core+line >> +types >> >> Part of the gemini canon? > > Why send the #5.4+Core+line+types part at all? Can't a client send the > URL without the anchor tag, and then use the anchor tag to automatically > scroll to the specified heading? Perhaps. How would that work? => gemini://gemini.circumlunar.space/docs/specification.gmi#5.4+Core+line+types vs. => gemini://gemini.circumlunar.space/docs/specification.gmi With the first link, a client could indeed scroll to the relevant header, if so inclined. How does the second scenario works?
> On Jun 9, 2020, at 22:09, solderpunk <solderpunk at SDF.ORG> wrote: > >> Why send the #5.4+Core+line+types part at all? Can't a client send the >> URL without the anchor tag, and then use the anchor tag to automatically >> scroll to the specified heading? > > Oh, sure, no need to send it to the server. Sorry, I missed the that > was what Sean was originally talking about. Aha! I see what you mean now. Yes, this could be handled solely on the client side. Thanks for the clarification. Still, no harm down if the fragment hit the server, right? Or?
On 6/9/20 8:12 PM, Petite Abeille wrote: > Perhaps. How would that work? > > => gemini://gemini.circumlunar.space/docs/specification.gmi#5.4+Core+line+types > vs. > => gemini://gemini.circumlunar.space/docs/specification.gmi > > With the first link, a client could indeed scroll to the relevant header, if so inclined. > > How does the second scenario works? Wouldn't it be infinitely easier and less vague to just use a line number for the fragment? Everything else is line based, so it fits that mindset well. It's also less likely to run into issues when someone has odd characters or multi-character emoji in a heading.
> Wouldn't it be infinitely easier and less vague to just use a line > number for the fragment? Everything else is line based, so it fits that > mindset well. It's also less likely to run into issues when someone has > odd characters or multi-character emoji in a heading. Any continuous numbering has the problem that the content needs to be perfectly static. No matter if you use line numbers or heading index. If I insert an introduction, a new sentence, update a date, ? the index will break
On 09-Jun-2020 21:00, solderpunk wrote: > On Tue, Jun 09, 2020 at 09:46:56PM +0200, Petite Abeille wrote: >> "A client SHOULD NOT send the fragment part of a URL to the server." >> -- Sean Conner, Resource request format for Gemini' states, circa 2019-08-01 >> https://portal.mozz.us/gemini/gemini.conman.org/gRFC/0002 >> >> Such restriction is not reflected in the spec itself. >> >> At the same time, the spec mentions header lines as "machine-readable representation of the internal structure of the document". >> >> Could one reflect such structure using fragments? >> >> E.g.: >> >> gemini://gemini.circumlunar.space/docs/specification.gm#5.4+Core+line+types >> >> Part of the gemini canon? > It's certainly something people have suggested. I guess to make it work > reliably would require a very strict specification of how to transform > headings into fragments, which sounds fiddly and dull... > > Either that, or we allow just numeric fragments like 3.2, which the > client is supposed to map to the second subsection of the third section. > The canonical way to do this in Markdown (and more widely on the web) seems to be lowercase kebab case of the alphabetic content, with single hyphens So it would be gemini://gemini.circumlunar.space/docs/specification.gm#core-line-types This is much more robust than having an offset index like 3.2, which will break all the links if you add a new section 1 to the page. I will probably implement this scheme in GemiNaut when I get round to it. The case insensitivity means you can change your mind about title casing on the heading and things still generally work fine. I think the behaviour can be the same as on the web where the fragment behaviour degrades well. If there is no such fragment, or the client does not support them, there is no scrolling to the offset. I think it is just a matter for the client authors to agree on (where they implement it). If it is in the spec, or accompanying guidance that might be nice, but not essential at the moment. Best wishes - Luke
On Tue, Jun 09, 2020 at 10:20:12PM +0200, Petite Abeille wrote: > Aha! I see what you mean now. Yes, this could be handled solely on the client side. Thanks for the clarification. > > Still, no harm down if the fragment hit the server, right? Or? > I guess robust servers *should* tolerate this without throwing an error. Cheers, Solderpunk
On 09-Jun-2020 21:26, solderpunk wrote: > On Tue, Jun 09, 2020 at 10:20:12PM +0200, Petite Abeille wrote: > >> Aha! I see what you mean now. Yes, this could be handled solely on the client side. Thanks for the clarification. >> >> Still, no harm down if the fragment hit the server, right? Or? >> > I guess robust servers *should* tolerate this without throwing an error. > > Cheers, > Solderpunk Yes servers should definitely ignore any such fragment, which should
I agree, this makes sense. Servers should be able to handle and ignore it, but clients should not be sending it at all either. The client I'm working on just strips it out of any URL. It'd be nice to see this explained in the spec. makeworld ??????? Original Message ??????? On Tuesday, June 9, 2020 4:29 PM, Luke Emmet <luke at marmaladefoo.com> wrote: > On 09-Jun-2020 21:26, solderpunk wrote: > > > On Tue, Jun 09, 2020 at 10:20:12PM +0200, Petite Abeille wrote: > > > > > Aha! I see what you mean now. Yes, this could be handled solely on the client side. Thanks for the clarification. > > > Still, no harm down if the fragment hit the server, right? Or? > > > > I guess robust servers should tolerate this without throwing an error. > > Cheers, > > Solderpunk > > Yes servers should definitely ignore any such fragment, which should > not be sent to the server. > > The query part of the URI is for server processing, the fragment is > always client side only as far as I understand it. > > https://en.wikipedia.org/wiki/Fragment_identifier > > - L
---