💾 Archived View for rawtext.club › ~sloum › geminilist › 002672.gmi captured on 2020-09-24 at 01:02:32. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Philip Linde linde.philip at gmail.com
Fri Sep 11 09:07:39 BST 2020
- - - - - - - - - - - - - - - - - - -
On Thu, 10 Sep 2020 23:17:19 -0700Nathan Galt <mailinglists at ngalt.com> wrote:
On the other hand, I think there’s a fairly, if not fully, general counterargument to all sorts of additions that we might want to make to the spec:
“There’s nothing wrong — or even uncool — about making a website with only HTML and, at most, 30 lines of CSS that looks great in Lynx.”
Thoughts? Counterarguments?
I agree with this notion. text/gemini has a very simple format, still.I think there are several good reasons for that being the case:
1. It's easy to parse. You can write a parser in an afternoon, and a renderer for the terminal or your favorite GUI toolkit that same evening2. It's easy to write pages. You can grasp every nuance of the document standard in an hour3. It's human readable. You can easily read a text/gemini page as plain text because the markup is minimal4. It has enough features to write very basic formatted documents, but not enough for the author to impose on the user
Similarly, for HTML, there are good reasons for it being structured asit is. It supports nested documents that allow for greater control offormatting, but at the expense of all the reasons I listed for Gemini.
If there is a good middle ground between HTML and Gemini, I'll happilysupport that as its own MIME type, but I think the final most importantcomplexity that text/gemini should address is that it shouldn't be a"living standard". That has a huge cost to site admins and developers.
-- Philip-------------- next part --------------A non-text attachment was scrubbed...Name: not availableType: application/pgp-signatureSize: 488 bytesDesc: not availableURL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200911/206a58ba/attachment.sig>