Meff meff at meff.me
Fri Sep 11 06:31:51 BST 2020
- - - - - - - - - - - - - - - - - - -
(Apologies for the double email Sean, I forgot to Reply All)
Sean Conner <sean at conman.org> writes:
And back in the mid-90s, there *were* plenty of web clients. Easily a
dozen that were easily available and that was back in time when it was easy
enough to parse HTML, there was no CSS and no Javascript, and it was
conceivable that someone could write a simple web browser in a weekend [1].
Then Sandra Snan sent the following link:
https://drewdevault.com/2020/03/18/Reckless-limitless-scope.html
Wherein it's mentioned that the current "state of the web" is described by
114,000,000 words spread across 1,217 standards documents. You get here by
incremental changes, all of which are "easy" and "it would be so
nice."
I agree with this. I understand that there's a couple points here thatthe alt-text discussion is trying to solve:
I don't see a way out of this without making Gemtext much morecomplicated than it is now. As it is, parsing Gemtext preformattedblocks requires holding onto state, which no other portion of Gemtextrequires. Adding hints will make parsing these blocks even morecomplicated. And then the interpretation question comes in: how do weinterpret these blocks that adorn preformatted text. Will these blocksbe abused. Will complicated clients adopt a de-facto meaning for these,leaving simpler clients to wither?
There are so many more questions that can come up. If I'm trying torepresent data, should Gemtext convey semantic information? If I'mrendering the contents of longform text, should Gemtext convey layoutinformation? And how do we reify layouts between different languages andtheir narrative structures? Should Gemtext support compression for largepayloads? What about caching? (ETags come to mind.) I mean, if I'mdistributing copies of Project Gutenberg books, I don't want to forcesomeone to download uncompressed text when they can get the same contentcompressed in often half the time, especially in low/bad connectivitysituations. Oh and how about math? I see lots of discussion about code,but how do we represent math? How do we give Gemini browsers renderinghints for math? The potential here to add complexity is endless!
Also, don't forget that Gemini can *easily* serve up HTML documents. And
Markdown documents. And PDF. And a host of other documentation formats
that all do what you want to do. And then some.
But hey, I can play this game. I added the following non-standard
document:
gemini://gemini.conman.org/test/preformat.gemini
that contains "machine readable text" at the opening preformatted marker,
and a "human readable text" on the ending preformatted marker, just to give
an indication of what it might look like and what might be done with it.
Enough talk, *someone* has to do an implementation to scare the bejeezus out
of everyone (not that it's particularly scary in what I did).
Thanks for putting the rubber to the road!
I'm just not a fan of trying to bundle more in Gemtext. I'd rather wetry to diversify the formats of content that are available. I think HTMLis a great fallback that can answer almost all the questions I posedearlier, the questions that are under discussion for alt text, and most questions of document presentation. HTML doesn't need to be deeplytied into a DOM with gobs of Javascript and CSS to work. And there'splaintext, PDFs, XML, JSON, tons of formats for all sorts of usecases. I'd rather not shove a round peg into a square hole, but that'sjust me.
- meff