-- Leo's gemini proxy
-- Connecting to auragem.letz.dev:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini; lang=en
This is part of my series on re-assessing the designs of Gemini and Gopher:
Yesterday I wrote quite a long article with a lot of concepts and ideas. It took me a long time to write, and was frankly pretty exhausting. So, today I'm taking a breather by discussing some features from the Web and from documents, and how they translate to Geminispace.
Headers on the web are interesting, because they serve multiple purposes:
To introduce the content
To associate all pages of a website under one banner
To present the overarching navigation of the website
The different elements of a header fall into the three categories above.
Content is introduced by the header through a page title, post date, byline, and other metadata information, including an image.
In Geminispace, we tend to put these things at the very start of the document. In my Scroll Protocol, the post date and author are put in the metadata so that the document becomes only the content plus the title.
This usually includes a logo and website/capsule title.
In geminispace, we have no mechanism for this aside from prepending all gemtext titles with the site title. I frequently do this on AuraGem (e.g., `AuraGem Music - profilename`). Instead, many browsers present the domain name as the title above the page, much like Lagrange does.
One potential way to solve this in my Scroll Protocol is to add a capsule title to the metadata of responses. Whether it's necessary is another question.
Components of a website that involve this would be navigation links that show up on every page of a website, a search bar/link, and even a user profile link and notifications.
Different capsules do this in different ways. Some put links at the very top of each page, while others don't put links on each page at all. Some put a "back" or "home" link, while others don't. Certainly some of this can be handled by better navigation in browsers:
If capsules are constructed more as a hierarchy of menus, then users are expected to go to the homepage to reach the top-level navigation. Switching between sister-pages - pages on the same level within the hierarchy - becomes tedious when you have to constantly go up the hierarchy (or back) to then click on another link. In Mozz's post above, he proposes some ideas to help fix this. I really wish they caught on within Geminispace, but they haven't yet, unfortunately. Even Lagrange doesn't have a way to see the previous page's links, which would be a simple thing that would help tremendously. VF-1 and AV-98 by solderpunk both have features similar to this.
Footers often contain navigation, a sitemap, the copyright and license info of the post or of the website, legal info, contact info, a logo, and links to user agreements and a privacy policy, as well as other legal information.
In Geminispace we can place all of this at the end of documents, but there's no semantic markup for it. Additionally, some of the footer elements conflates the content of the site with the content of the document, which may not be desired. Website-wide or Capsule-wide information should probably be placed on the homepage. However, the reason footers are common is because its content is easily accessed from everywhere on the site.
Perhaps better browser navigation or better metadata in the protocol could provide some interesting solutions.
There are two general categories for sidebars, one that is more content-focused than the other:
Navigation, filters, search
Outlines, aside info, related links/content
This is a distinction between how sidebars are most commonly used in books and documents vs. how sidebars are most used in websites (especially in a more website-as-apps setting).
The benefit of a sidebar on the web is that it reduces vertical clutter by placing the sidebar to the side of the main content. In books, it detaches the aside info from the main content because it provides extra, and not always essential, information. A downside is that clients have to deal with how to present sidebars on the screen.
Currently, Gemtext has no way of marking either of these things. However, for some elements it could be unnecessary. For example, search on the web takes a lot of visual space, but search in Gemtext is just a link. Outlines are necessary on the web, but they are not in Gemtext because clients can easily generate outlines. Geminispace tends to split up pages in a hierarchy where navigation links become the content of those menus, whereas the web will try to put navigation and content side-by-side. The only thing that we might want in Gemtext is a way of marking *aside content*, like what you might find in sidebars in textbooks.
Footnotes don't exactly work in a document system that doesn't have clearly delineated pages, like with markdown and gemtext. However, we can have notes at the end of heading sections. I will be calling these "footnotes".
Footnotes and Endnotes are typically related to content. They either cite other works, add additional (sometimes non-essential) information to the content, almost like an aside, or they do both.
Most of the time footnotes are one paragraph, but they *can* sometimes be multiple paragraphs. If they include a citation, they might include links as well.
Gemtext has no semantic markup for footnotes, but there is a fairly consistent syntax for it that writers use in plaintext, which is square brackets with a number placed inside them. [1] Parsers, unfortunately, cannot parse these because they are highly contextual, meaning that there are various other reasons why a document puts numbers into square brackets outside of footnotes and endnotes, and parsers cannot always tell the difference. Perhaps more research on the usage of numbers in brackets is required to see how common other usages of them are.
Markdown came up with its own syntax by using the same numbers inside brackets, but by placing a caret just before the number (to represent that it's superscripted). This works very well. Parsers don't need to have parsed the footnote later on to know that this is a link to a later footnote. The main downside is writers need to get used to this syntax. [^2]
The benefit of semantic markup for footnotes is that parsers can present them differently from the rest of the text, and crawlers and clients that analyze documents can store information about them differently, and interpret them differently.
The two downsides to markdown's footnote syntax are these:
There's no way to do multiple paragraphs in one footnote.
There's no way to put markup links in a footnote.
The other downside is that it's not nearly as easy to parse as the other linetypes within gemtext. But this is just a matter of finding the right syntax.
[1] This is a footnote in plain text.
[^2] This is Markdown's footnote syntax. Yes, I'm well aware that it's mainly an extension and not part of a lot of Markdown standards.
-- Response ended
-- Page fetched on Mon May 6 11:14:49 2024