4 ms·

https://gemini.circumlunar.space/docs/faq.gmi https://gemini.circumlunar.space/docs/faq.gmi > 2.5 Why not just use a subset of HTTP and HTML? > [...] > The p

by kixiQu 5y ago

https://gemini.circumlunar.space/docs/faq.gmi https://gemini.circumlunar.space/docs/faq.gmi > 2.5 Why not just use a subset of HTTP and HTML? > [...] > The problem is that deciding upon a strictly limited subset of HTTP and HTML, slapping a label on it and calling it a day would do almost nothing to create a clearly demarcated space where people can go to consume only that kind of content in only that kind of way. It's impossible to know in advance whether what's on the other side of a https:// https:// URL will be within the subset or outside it. It's very tedious to verify that a website claiming to use only the subset actually does, as many of the features we want to avoid are invisible (but not harmless!) to the user. It's difficult or even impossible to deactivate support for all the unwanted features in mainstream browsers, so if somebody breaks the rules you'll pay the consequences. Writing a dumbed down web browser which gracefully ignores all the unwanted features is much harder than writing a Gemini client from scratch. I'd get a kick out of a markdown-web, personally.

Jtsummers 5y ago
That's a fair argument for not saying, "We're going to make our servers only use a subset of HTTP and HTML." However, it neglected the potential to support a subset of HTML (or XHTML if they wanted to avoid the parsing complexity of HTML5) on Gemini itself.
- kixiQu 5y ago
  At that point I think the choice gets back to their whole goal of > A client comfortable for daily use which implements every single protocol feature should be a feasible weekend programming project for a single developer. This isn't a particularly appealing protocol characteristic to me, but YMMV.
  - ludamad 5y ago
    These days, integrating an HTML engine into a project is feasible in a weekend. It gets weird measuring the time to write software already written
kixiQu 5y ago
Ah, but just for completeness, despite my own fondness for the idea of a markdown-web, their faq states: > 2.9 Why didn't you just use Markdown instead of defining text/gemini? > The text/gemini markup borrows heavily from Markdown, which might prompt some people to wonder "Why not just use Markdown as the default media type for Gemini? Sure, it's complicated to implement, but like TLS there are plenty of libraries available in all the major languages". Reasons not to go down this route include: > There are actually many subtly different and incompatible variants of Markdown in existence, so unlike TLS all the different libraries are not guaranteed to behave similarly. > The vast majority of Markdown libraries don't actually do anything more than convert Markdown to HTML, which for a Gemini client is a needless intermediary format which is heavier than the original! > Many Markdown variants permit features which were not wanted for Gemini, e.g. inline images. > A desire to preserve Gopher's requirement of "one link per line" on the grounds that it encourages extremely clear site designs. > Of course, it is possible to serve Markdown over Gemini. The inclusion of a text/markdown Media type in the response header will allow more advanced clients to support it. My experience of Gemini's "one link per line" deal has not suggested it leads to "extremely clear site designs", but I'm also not a Gopher person so maybe I'm missing The Paradigm.
- kelnos 5y ago
  The argument seems to boil down to "these other formats have many variants or features that we don't want, so we're going to invent something new". That... just does not make sense. I get that they admit that they do borrow heavily from Markdown, but there's no reason why they can't pick features from Markdown (including inline links and images), put them in their spec, and still call it "gemtext". The real reason they don't do this is right there: they don't want to. They decided on a weak set of features, leaving out things that most people probably would find useful, and that's that. I do understand the desire to limit features and extensibility, to avoid Gemini turning into the mess that is the current state of web standards, not to mention the attractiveness of being able to cut off ads and tracking by design. But I agree with OP that they're going about it in a way that all but guarantees they will not be particularly successful. Telling users they can't have inline links or images, and telling developers their creativity in implementation is severely limited isn't going to make you many friends. And maybe that's also by design. If they want to recreate the internet of the 80s and early 90s, including the "feature" that a very tiny percentage of humanity was on it, maybe this really is the way to do it. I wish them well, but I don't think this would be an ecosystem that would give me joy (no judgment, and I'm sure the Gemini folks don't care, and that's all fine).

by kixiQu 5y ago

Jtsummers 5y ago

That's a fair argument for not saying, "We're going to make our servers only use a subset of HTTP and HTML." However, it neglected the potential to support a subset of HTML (or XHTML if they wanted to avoid the parsing complexity of HTML5) on Gemini itself.

kixiQu 5y ago
At that point I think the choice gets back to their whole goal of > A client comfortable for daily use which implements every single protocol feature should be a feasible weekend programming project for a single developer. This isn't a particularly appealing protocol characteristic to me, but YMMV.
- ludamad 5y ago
  These days, integrating an HTML engine into a project is feasible in a weekend. It gets weird measuring the time to write software already written

kixiQu 5y ago

Ah, but just for completeness, despite my own fondness for the idea of a markdown-web, their faq states: > 2.9 Why didn't you just use Markdown instead of defining text/gemini? > The text/gemini markup borrows heavily from Markdown, which might prompt some people to wonder "Why not just use Markdown as the default media type for Gemini? Sure, it's complicated to implement, but like TLS there are plenty of libraries available in all the major languages". Reasons not to go down this route include: > There are actually many subtly different and incompatible variants of Markdown in existence, so unlike TLS all the different libraries are not guaranteed to behave similarly. > The vast majority of Markdown libraries don't actually do anything more than convert Markdown to HTML, which for a Gemini client is a needless intermediary format which is heavier than the original! > Many Markdown variants permit features which were not wanted for Gemini, e.g. inline images. > A desire to preserve Gopher's requirement of "one link per line" on the grounds that it encourages extremely clear site designs. > Of course, it is possible to serve Markdown over Gemini. The inclusion of a text/markdown Media type in the response header will allow more advanced clients to support it. My experience of Gemini's "one link per line" deal has not suggested it leads to "extremely clear site designs", but I'm also not a Gopher person so maybe I'm missing The Paradigm.

kelnos 5y ago
The argument seems to boil down to "these other formats have many variants or features that we don't want, so we're going to invent something new". That... just does not make sense. I get that they admit that they do borrow heavily from Markdown, but there's no reason why they can't pick features from Markdown (including inline links and images), put them in their spec, and still call it "gemtext". The real reason they don't do this is right there: they don't want to. They decided on a weak set of features, leaving out things that most people probably would find useful, and that's that. I do understand the desire to limit features and extensibility, to avoid Gemini turning into the mess that is the current state of web standards, not to mention the attractiveness of being able to cut off ads and tracking by design. But I agree with OP that they're going about it in a way that all but guarantees they will not be particularly successful. Telling users they can't have inline links or images, and telling developers their creativity in implementation is severely limited isn't going to make you many friends. And maybe that's also by design. If they want to recreate the internet of the 80s and early 90s, including the "feature" that a very tiny percentage of humanity was on it, maybe this really is the way to do it. I wish them well, but I don't think this would be an ecosystem that would give me joy (no judgment, and I'm sure the Gemini folks don't care, and that's all fine).