💾 Archived View for rawtext.club › ~sloum › geminilist › 005617.gmi captured on 2024-02-05 at 11:08:53. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Omar Polo op at omarpolo.com
Thu Feb 25 11:40:47 GMT 2021
- - - - - - - - - - - - - - - - - - -
Oliver Simmons <oliversimmo at gmail.com> writes:
On Thu, 25 Feb 2021 at 09:17, Omar Polo <op at omarpolo.com> wrote:
I think this is a bogus point. I never contributed to OSM, but from
what you're saying I suppose they use something like XML/SGML/... Those
things are *meant* for extensions (the 'X' in XML stands for that),
whilst everything around Gemini is focused on non-extensibility and
simplicity, even at cost of missing features.
I'm not talking about XML/etc, that's an entirely separate topic.
I'm talking about the key=value system.
But instead of thinking about what we may add, let's think about what we
have:
- we have TLS because it's fundamental to guarantee confidentiality
between servers and clients
- we have status codes, because a page that says "an error occurred"
or "certificate required" cannot be interpreted correctly otherwise
- we have a media-type in the response, so users know what kind of
document they're getting
These are all about the protocol, not Gemtext.
While it's true that the protocol and gemtext are two different things(I can serve HTML over gemini and text/gemini over HTTP), they are closeto each other, and it conveys the point that Gemini is made ofpractically only needed stuff, nothing more.
(I read about the Mercury protocol, which I didn't knew, and it's reallyinteresting, but only if you don't consider TLS essential, which I do.)
- we have links, so we can connect different pages, even across
different capsules
- we have titles, paragraphs, quotes and lists to express and organize
our writings
- we have pre-formatted blocks to allow certain types of
explanations/presentations that otherwise would have been impossible
(how do we teach how to write text/gemini in text/gemini?)
From here you can notice how humanly-centric Gemini is. We don't have
features for bots (more than what it's absolutely needed at least) and
even more importantly we only have basic and necessary stuff. There's
no fluff in Gemini.
If you think about it, we only have features that we can't objectively
live without (no links? no paragraphs? no media-types? ...) while we're
lacking various things that would be "nice to have".
Specification section 5.5 - Advanced line types:
The following advanced line types MAY be recognised by advanced clients.
Simple clients may treat them all as text lines as per 5.4.1 without any loss of essential function.
I agree though, unnecessary features shouldn't be added.
We don't have headers, because with them comes extensibility and
complexities, and we're getting just fine without them. We don't have
inline formatting because it's difficult to handle client-side and we're
doing really fine without, etc.
Extensibility *is* an issue with metadata, but this applies to Gemtext
as a whole due to its nature of being text-based, who's to stop
someone from creating a new line type that their client understands?
Standardising metadata now would make people less likely to add it in
their own weird formats in the future, and laying down solid rules of
what is and isn't allowed as metadata in Gemini documents helps in
avoiding (it doesn't prevent entirely) people from adding styling or
other weird things in the future.
It's attrition that will prevent things like this in the future, notstandardisation. For example, I can create a Gemini client thatsupports a script-type line, like
-~ alert("hello world");
but then I would have to convince this list, people who write contentand people who write clients and tools to recognise the -~ line type andcope with that. I don't think it will gain traction, so...
On the opposite side, adding metadata would make it easier for people
to add new things like styling, if they ignore what it's intended for.
Neither side of the argument really wins here in my eyes.
...not having metadata is slightly better then because people would haveto come up with a syntax, implement it in their clients and convinceothers to do the same while looking weird in the eyes of others. Havinga standardised syntax for it allows from day-one someone to say`background-image: kittens.png' and be fine with that, without lookingweird to other people browsing his/hers capsule.
It's similar to why we don't have headers in the protocol: becausesomeone, somewhere at some time will abuse them. Having faith in thecommunity is a good thing, but ensuring that certain things aren'tpossible is better.
One thing that I haven't though about when writing the mail, but onlylater when discussing the matter with thfr@, is that we're trying tohide stuff from users eyes. Sure, if used correctly those two proposedsyntaxes (=: and ^^^) can be easy to read, but lets be honest: clientswon't show them as-is, in particular the more advanced ones.
As things stands now, there are only two things that Gemini clientsusually hide: the URL of a link-line and the alt-text of a pre-formattedblock. There's a understandable UX reason for that, but do we reallyneed to add something else that we know will be hidden to end users?
(Yeah, clients also hide the `#' and `=
' usually too, but that's notcount as "hiding stuff" IMHO, and they usually provide ways to see theURL or alt text, or even the raw text/gemini)
Another thing that I forgot to explicitly say in my previous message isthat we can use some sort of common notation, a convention, rather thanadding new things to the specification. See for instance the"Subscribing to Gemini pages" companion specification: a lightweight,convention-based way to provide atom-like feeds. I found it prettyelegant, and has proven a) easy to implement b) easy for content writersto use c) easy for end-users to consume and d) avoid adding extra linetypes/file types/etc to the specification.
[snip]
Now, to get off-topic:
[0]: mine? I would love to have a syntax for definition lists and
3-levels of unordered lists.
If you mean ordered lists with your first point they would be ~fairly
hard for clients to parse compared to other line types, they don't
start with a static first three characters. (See spec section 5.3 -
"Line-orientation")
1. Hi
2. Foo
3. Bar
Works fine anyways with plain text, it just doesn't have as nice
line-wrapping as quotes and unordered lists.
No, I mean definition lists. They're like dictionary entries, where youprovide a term and then its definition. In LaTeX is
\begin{definition} \item[foo] definition of foo \end{definition}
in mandoc
.Bl -tag .It foo definition of foo .El
in HTML <dl>/<dd>/<dt>. I find them super-useful when explainingthings, even if they aren't as widespread as other types of lists. I'memulating them with
but this was just a kind of moot point to show that everyone here wouldlike to add something to the spec probably, but in the end we're doingjust fine as things are.
Multiple levels of unordered lists actually wouldn't be very hard:
* Hi
** And welcome
*** to my list
* Boop!
** Booyah!
there were a proposal for that some time ago, but it didn't gainedtraction and died. Amen :/
[1]: .gms is GeminiScript of course. A minimal, non-estensibile and
simple scripting language for your preferred client, hoping it
doesn't lack support for it /s
burn. it. with. fire.
- Oliver Simmons (GoodClover)