31–40 of 113 posts
Markdown is way better IMO, also very simple yet allowing for better visuals and more expressivness, and new protocol should be designed to use it as its text format.
Markdown is, uh, not so good, it just won a popularity cintest. E.g. Creole is much better. https://en.wikipedia.org/wiki/Creole_(markup)
Markdown is way better IMO, also very simple yet allowing for better visuals and more expressivness, and new protocol should be designed to use it as its text format.
No, Markdown is a format for authoring HTML. It makes a very bad interchange format because the it leaves too much ambiguity in parsing. Also, parsing speed of Markdown is much slower than the parsing speed of a strictly conforming XML file.
Parsing Markdown is fast enough.
This protocol looks like someone didn't exactly know how HTTP worked, and more importantly, from where the bloat came from, then tried to do something too simple. Then went on not understanding why people value Markdown, and do something entirely worse, without any good reason.
I think you just misunderstand the point. A lot of criticism of Gemini seems to make the assumption that it's intended to replace HTTP and that it's badly thought through for that use. In fact, I think it basically came from a niche group of Gopher hobbyist users who wanted to fix a few longstanding annoyances with Gopher. They wanted something that anybody could write a client or server for as a fun little weekend p…
If you want protocol to be light and low on bandwidth, why would you not include at least the simplest of caching semantics ?
It is just bad design decision after bad design decision
Markdown is way better IMO, also very simple yet allowing for better visuals and more expressivness, and new protocol should be designed to use it as its text format.
Markdown is, uh, not so good, it just won a popularity cintest. E.g. Creole is much better. https://en.wikipedia.org/wiki/Creole_(markup)
Earlier quoted context omitted.
> As a proponent of the Gemini protocol, I take issue with this line. The Gemtext format is a minimal markup format for text documents. It's a way of semantically indicating "this part is plaintext", "this part is a link", "this part is a header". Unlike HTML/CSS, it does not provide a mechanism for the author to style their documents. Instead, it is up to the client to render the text document, however the client ch…
> What does it add that markdown does not have ? "a satisfactory rendering can be achieved with a single pass of a document, processing each line independently" - from what I understand of Markdown parsing, it's a lot more complex than this because of the spec. > There appears to not even be a support for a basic table Given the number of Markdown table attempts I've seen over the years, I don't blame them for wantin…
>"a satisfactory rendering can be achieved with a single pass of a document, processing each line independently" - from what I understand of Markdown parsing, it's a lot more complex than this because of the spec.
If your device don't have enough memory to parse the markdown document it can just display it. That's not an useful feature of a format. Hell, if it is really a problem use subset of it instead of using half, then inventing own, worse way, to add URLs into the text.
>> There appears to not even be a support for a basic table
>Given the number of Markdown table attempts I've seen over the years, I don't blame them for wanting to avoid that plague pit. Plus then rendering tables is another hellscape of torment.
If you don't we're back in ugly land of mono font manually setting it up, that's why I think that should be included in bare minimum of any markup format. But that's kinda beside the point as originally MD didn't had it either.
Earlier quoted context omitted.
Gemtext has the pre formatted text fence that it specs as a mode-switch. Is that impossible with markdown? I think you could probably design every control symbol in markdown as a switch to “bold mode”, or “link content mode” and leave it at that. State machine style I guess?
> Is that impossible with markdown? No, that bit is the simple bit. > you could probably design every control symbol in markdown as a switch You need a layered mode though - you can have bold, italic, monospaced, header and link all active at the same time - which means you've got 32 states right there. But also! If you do something like `# Header _*bold-italic`, that italic and bold don't apply because the EOL stops…
Requiring like, a byte, for state is hardly a complex requirement.
> But also! If you do something like `# Header _bold-italic`, that italic and bold don't apply because the EOL stops the header state and retroactively cancels those bold-italic attributes.
And an IF statement or two.
> But also also! If you mismatch the order, it won't match both. Or, at least in Marked 2, if you mismatch the order on both sides of a non-attributed word, that word will get the wrong styling (`_with mismatched_* middle _attributes_`).
Fair enough, but you can't expect to get correct output if you put wrong data in, you are trying to italicize it twice. If the interpreteation was "either * or _ turns italics on/off" you'd also have not what you expected.
My complaint about markdown here is really that there are 2 ways to make italics and 2 ways to make bold text. "Just" having * for bold and _ for italics would on top of making parsing easy also make it clearer. Less typing too.
The high-level criticism, which is that Gemini's specification is too loose and vague, seems very, very convincing, even if the specifics aren't. In a subtle way, this is a significant hurdle for any competitors to the HTTP world. They have to overcome 30 years of technical debate and refinement as ambiguities have been hammered down.
Gemini isn't a competitor to HTML, it's an alternative .
What if... Markdown was its own MIME type and browsers rendered it with a default stylesheet? :thinking_emoji:
I think it should be a thing anyway. If Blink, Webkit and Firefox have compatible implementations there can be some sort of de facto standard and it will be fine for a number of actually useful things, even if it's not perfectly defined to pocket protector standards.
Markdown is way better IMO, also very simple yet allowing for better visuals and more expressivness, and new protocol should be designed to use it as its text format.
Markdown is, uh, not so good, it just won a popularity cintest. E.g. Creole is much better. https://en.wikipedia.org/wiki/Creole_(markup)
No markup syntax is straight up worse