💾 Archived View for rawtext.club › ~sloum › geminilist › 002677.gmi captured on 2020-11-07 at 03:04:17. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
Gary Johnson lambdatronic at disroot.org
Fri Sep 11 18:51:06 BST 2020
- - - - - - - - - - - - - - - - - - -
It's true that the Gemini protocol is able to serve up a variety of fileformats given its explicit requirement of mime-types in responsemetadata. I'm also happy with the simple stripped-down nature of theGemtext format and am not looking for any major changes to be made to itat this time.
However, I do want to throw in a counterpoint to recommending peopleabandon Gemtext and serve up more Markdown or HTML in Geminispace.
While it is true that they can all be served up by the Gemini protocol,it is not currently the case that very many Gemini clients can renderanything other than Gemtext. If enough people start to publish inMarkdown and/or HTML, we may soon find our experience of surfingGeminispace to largely be about downloading Markdown and HTML pageswhenever we click on links and then having to open the local files inour format-specific renderers of choice. HTML pages also reintroduce theissue of potentially requiring clients to download any number ofauxiliary pages in order to render them. While we could hope that Geminipublishers will stick to a minimal subset of HTML (for each user'svarying definition of "minimal"), there is no way to enforce this.
This does not sound like much fun to me, and it would impose a muchhigher development cost on each browser developer as they would have toimplement rendering engines for Gemtext, Markdown, HTML, etc. in orderto provide their users with a more seamless browsing experience. Givenuneven distribution of resources to maintain and extend clients, thiscould drive us down a path in which a smaller and smaller number ofbrowsers come to dominate Geminispace as the number of requirements onwhat they have to render continues to increase.
In a worst-case scenario, we ultimately end up recreating a post-webmonopoly of Geminispace.
Just my 2c, but I'd like to see more folks encouraging the use oftext/gemini or text/plain in Geminispace rather than punting to morecomplex formats except in special cases. If anyone is feeling superrestricted by Gemtext, I'd encourage them to spend some time onAstrobotany (gemini://astrobotany.mozz.us) for inspiration.
YMMV, Gary
Alex // nytpu <alex at nytpu.com> writes:
If there is a good middle ground between HTML and Gemini, I'll happily
support that as its own MIME type
While I understand the desire to have something novel, there really is
no need to reinvent the wheel here. The whole point of having mimetypes
in gemini is so you can use whatever format you want to serve content.
If you want basic linking and sections, use gemtext. If you want rich
formatting (emphasis, boldface, etc) use markdown or asciidoc or any of
a million lightweight markup languages. If you want deep control over
the presentation of the document, use html. If you want no formatting at
all, use plaintext. There's near certainty that there's an existing
format that generally suits your needs unless you're doing something
like math formulae, and even then you could just link to an image or use
a pdf and LaTeX.
The thing is, I think people have a misconstrued idea of what gemtext
is. The long and short of it is that it's a gophermap with headers and
code blocks. Sure, the syntax is different but at the end of the day
that's all it is. If you can't live without stronger control over the
styling and document structure you should just use a subset of html
(There's absolutely nothing wrong with that! You can still browse gemini
without having a gemini capsule yourself). You could even serve your
html over gemini if you so chose, although I'm not sure how well it'd be
supported by clients.
but I think the final most important complexity that text/gemini
should address is that it shouldn't be a "living standard". That has a
huge cost to site admins and developers.
I think this should aim to be the highest priority over "making gemtext
better." Obviously there's an exception right now since it's in the
early stages and not finalized yet, but even now there shouldn't be
massive changes made to the spec at all, let alone changes that turn
gemtext into an ad hoc, impossible-to-parse implementation of half of
html.
-- GPG Key ID: 7BC158EDUse `gpg --search-keys lambdatronic' to find meProtect yourself from surveillance: https://emailselfdefense.fsf.org=======================================================================() ascii ribbon campaign - against html e-mail/\ www.asciiribbon.org - against proprietary attachments
Please avoid sending me MS-Office attachments.See http://www.gnu.org/philosophy/no-word-attachments.html