Thanks for putting together a simple example Gemtext file using the
machine-readable-on-top, alt-text-on-bottom approach I suggested
yesterday.
>From the recent mailing list responses, it looks like my proposal was
met with mixed feelings. Some of you liked it. Others didn't and
suggested using HTML or Markdown instead. There also appear to be
several folks harboring fears of a slippery slope situation in which the
Gemini protocol, by means of supporting a machine-readable text line on
its preformatted text blocks, is somehow going to become as complex as
the modern-day web. I'll try to address some of these concerns here.
Just stepping back to first principles, I believe Solderpunk's intention
with the Gemtext spec was to provide a slightly more structured markup
format than plain text that could look nice in a more complex client but
which would still render just fine in a client that did nothing more
than render text/gemini as text/plain.
While I believe that Gemtext accomplishes this purpose very well in its
current state, the preformatted text block is definitely overloaded at
the moment in terms of its purpose. Currently, it is the only way to
include images (as ASCII art), tables, or source-code blocks in a
guaranteed mono-spaced font. All of these provide valuable information
to readers of our Gemtext pages, and I personally am quite happy with
how simple the preformatted blocks make it to include them.
However, once of the issues I first wrote to Solderpunk about when I
became aware of Gemini was whether Gemtext would support optional syntax
highlighting (in advanced clients that chose to support it) by allowing
us to use the ```some-programming-language syntax from Github-flavored
Markdown on the opening line of preformatted blocks. He replied to me
saying that this had been considered already and was intended as one of
the uses of that slot. He also pointed me to the point in the Gemini
spec which mentions this. Here is the relevant paragraph from Section
5.4.3 Preformatting toggle lines:
> Any text following the leading "```" of a preformat toggle line which
> toggles preformatted mode on MAY be interpreted by the client as "alt
> text" pertaining to the preformatted text lines which follow the
> toggle line. Use of alt text is at the client's discretion, and simple
> clients may ignore it. Alt text is recommended for ASCII art or
> similar non-textual content which, for example, cannot be meaningfully
> understood when rendered through a screen reader or usefully indexed
> by a search engine. Alt text may also be used for computer source code
> to identify the programming language which advanced clients may use
> for syntax highlighting.
For the three use cases of preformatted blocks that I mentioned above
(ASCII art images, tables, source code), alt text (as an accessibility
option) could clearly be useful and is also obviously the intended
purpose of this slot. However, the last line of that paragraph indicates
the intention that the ```some-programming-language is meant as one
machine-readable use of the line's contents for the purpose syntax
highlighting.
To assuage any concerns about opening the door to endless possible
syntaxes for machine-readable processing of preformatted blocks being
introduced to Gemtext, I'll retract my previous suggestion of using the
top line for (generic) machine-readable purposes and the bottom line for
the alt text.
The only real machine-readable behavior I want to see in Gemini is
source code syntax highlighting anyway, and the spec already supports
and encourages that. In all other cases, alt text (which can clearly be
ignored or used "at the client's discretion" as per the spec) is just
fine on the top line of preformatted blocks. I suppose I don't really
see much machine-readable value in tagging a block as "image" or "table"
currently anyway. YMMV
To that end, maybe we just need some community agreement (and/or a
clearer codification in the Gemini spec) of how to use alt text "for
computer source code to identify the programming language which advanced
clients may use for syntax highlighting".
===========================================================================
Here's a simple proposal:
```clojure Source code implementing a non-tail-recursive factorial function
(defn fac [n]
(if (= n 0)
1
(* n (fac (- n 1)))))
```
If the first word in a preformatted text block's alt text is the name of
a programming language recognized by the client, then it may (at its
discretion) apply syntax highlighting for that language to the block's
contents.
===========================================================================
This remains in line with both the spirit and content of Gemini
specification Section 5.4.3 Preformatting toggle lines. It also
explicitly allows clients to opt-in (or not). Whether or not syntax
highlighting is applied, the entire alt text line can still be used as
perfectly valid human-readable text for accessibility purposes.
There is no possibility of a slippery slope happening in the Gemtext
specification because this is just a non-extensible, optional-only
feature that is already in the Gemini spec anyway and is just being more
clearly codified, so it can be used reliably in the wild.
I yield the floor.
Thanks,
Gary
Meff <meff at meff.me> writes:
> (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
--
GPG Key ID: 7BC158ED
Use `gpg --search-keys lambdatronic' to find me
Protect yourself from surveillance: https://emailselfdefense.fsf.org
=======================================================================
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
Please avoid sending me MS-Office attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
---
Previous in thread (35 of 50): 🗣️ Sean Conner (sean (a) conman.org)
Next in thread (37 of 50): 🗣️ Luke Emmet (luke (a) marmaladefoo.com)