5 ms·

I personally don't understand why they just couldn't use markdown or simple HTML 3.2. As an aside, there's honestly not even anything wrong with HTML 4.0 as a

by ronsor 5y ago

I personally don't understand why they just couldn't use markdown or simple HTML 3.2. As an aside, there's honestly not even anything wrong with HTML 4.0 as a format. Up until the beginning of the 2010s, it was perfectly practical to create a third-party browser implementation supporting CSS 2 and HTML 4.

bsder 5y ago
The problem is text rendering that exceeds what a VT100 can produce. As soon as you enter that realm, your browser complexity goes exponential.
- dredmorbius 5y ago
  Semantic document structure need not have a fixed presentation. Old-school UMIX manpages written in roff were most often displayed on VT-100 terminals, were designed to be compatible with teletypes, and yet could be printed pretty-formatted in variable-width fonts with true italic, bold, and point sizes. You can still see this, e.g.: man -Tps clear | ps2pdf > clear.pdf Open that and you'll find a fully typeset document. Which is kind of the point of semantic markup: it is independent of presentation.
  - bsder 5y ago
    Except that you rendered to Postscript--which is a general, stack based programming language (with a bunch of domain specific font manipulation code baked into it as well). Thus demonstrating my point that the moment you go above a VT100 in presentation quality, your complexity goes exponential.
    - dredmorbius 5y ago
      The point is that the same markup source produces different output endpoints depending on the device and capabilities available. Straight ASCII text, possibly with ANSI sequences, for a terminal. Fully typeset output for a raster display or printer. What you're raising as an objection is actually the entire point of my example.
      - bsder 5y ago
        The complexity of the markup isn't relevant. The complexity of the renderer is. And you are grossly underestimating the complexity of even an ASCII typesetting engine. RUNOFF/nroff/troff/ditroff/groff isn't even easy for a character device like a vt100. The developers of those engines reads like a who's who of computing luminaries. My point as to why rewriting a web browser is hard is that you are developing a "typesetting engine", and developing a typesetting engine is HARD.
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

by ronsor 5y ago

bsder 5y ago

The problem is text rendering that exceeds what a VT100 can produce. As soon as you enter that realm, your browser complexity goes exponential.

dredmorbius 5y ago
Semantic document structure need not have a fixed presentation. Old-school UMIX manpages written in roff were most often displayed on VT-100 terminals, were designed to be compatible with teletypes, and yet could be printed pretty-formatted in variable-width fonts with true italic, bold, and point sizes. You can still see this, e.g.: man -Tps clear | ps2pdf > clear.pdf Open that and you'll find a fully typeset document. Which is kind of the point of semantic markup: it is independent of presentation.
- bsder 5y ago
  Except that you rendered to Postscript--which is a general, stack based programming language (with a bunch of domain specific font manipulation code baked into it as well). Thus demonstrating my point that the moment you go above a VT100 in presentation quality, your complexity goes exponential.
  - dredmorbius 5y ago
    The point is that the same markup source produces different output endpoints depending on the device and capabilities available. Straight ASCII text, possibly with ANSI sequences, for a terminal. Fully typeset output for a raster display or printer. What you're raising as an objection is actually the entire point of my example.
    - bsder 5y ago
      The complexity of the markup isn't relevant. The complexity of the renderer is. And you are grossly underestimating the complexity of even an ASCII typesetting engine. RUNOFF/nroff/troff/ditroff/groff isn't even easy for a character device like a vt100. The developers of those engines reads like a who's who of computing luminaries. My point as to why rewriting a web browser is hard is that you are developing a "typesetting engine", and developing a typesetting engine is HARD.

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