A proposed scheme for parsing preformatted alt text

[Meff]

(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 that
the alt-text discussion is trying to solve:

* Formatting hints for non-human clients
** Specifically this benefits users that may be visually impaired and
   their use of tools such as screen readers
* Hints or descriptions for human readers

I don't see a way out of this without making Gemtext much more
complicated than it is now. As it is, parsing Gemtext preformatted
blocks requires holding onto state, which no other portion of Gemtext
requires. Adding hints will make parsing these blocks even more
complicated. And then the interpretation question comes in: how do we
interpret these blocks that adorn preformatted text. Will these blocks
be 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 to
represent data, should Gemtext convey semantic information? If I'm
rendering the contents of longform text, should Gemtext convey layout
information? And how do we reify layouts between different languages and
their narrative structures? Should Gemtext support compression for large
payloads? What about caching? (ETags come to mind.) I mean, if I'm
distributing copies of Project Gutenberg books, I don't want to force
someone to download uncompressed text when they can get the same content
compressed in often half the time, especially in low/bad connectivity
situations. Oh and how about math? I see lots of discussion about code,
but how do we represent math? How do we give Gemini browsers rendering
hints 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 we
try to diversify the formats of content that are available. I think HTML
is a great fallback that can answer almost all the questions I posed
earlier, the questions that are under discussion for alt text, and 
most questions of document presentation. HTML doesn't need to be deeply
tied into a DOM with gobs of Javascript and CSS to work. And there's
plaintext, PDFs, XML, JSON, tons of formats for all sorts of use
cases. I'd rather not shove a round peg into a square hole, but that's
just me.

- meff