💾 Archived View for rawtext.club › ~sloum › geminilist › 002676.gmi captured on 2020-11-07 at 03:04:13. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
Gary Johnson lambdatronic at disroot.org
Fri Sep 11 18:28:55 BST 2020
- - - - - - - - - - - - - - - - - - -
Thanks for putting together a simple example Gemtext file using themachine-readable-on-top, alt-text-on-bottom approach I suggestedyesterday.
From the recent mailing list responses, it looks like my proposal wasmet with mixed feelings. Some of you liked it. Others didn't andsuggested using HTML or Markdown instead. There also appear to beseveral folks harboring fears of a slippery slope situation in which theGemini protocol, by means of supporting a machine-readable text line onits preformatted text blocks, is somehow going to become as complex asthe modern-day web. I'll try to address some of these concerns here.
Just stepping back to first principles, I believe Solderpunk's intentionwith the Gemtext spec was to provide a slightly more structured markupformat than plain text that could look nice in a more complex client butwhich would still render just fine in a client that did nothing morethan render text/gemini as text/plain.
While I believe that Gemtext accomplishes this purpose very well in itscurrent state, the preformatted text block is definitely overloaded atthe moment in terms of its purpose. Currently, it is the only way toinclude images (as ASCII art), tables, or source-code blocks in aguaranteed mono-spaced font. All of these provide valuable informationto readers of our Gemtext pages, and I personally am quite happy withhow simple the preformatted blocks make it to include them.
However, once of the issues I first wrote to Solderpunk about when Ibecame aware of Gemini was whether Gemtext would support optional syntaxhighlighting (in advanced clients that chose to support it) by allowingus to use the ```some-programming-language syntax from Github-flavoredMarkdown on the opening line of preformatted blocks. He replied to mesaying that this had been considered already and was intended as one ofthe uses of that slot. He also pointed me to the point in the Geminispec which mentions this. Here is the relevant paragraph from Section5.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 accessibilityoption) could clearly be useful and is also obviously the intendedpurpose of this slot. However, the last line of that paragraph indicatesthe intention that the ```some-programming-language is meant as onemachine-readable use of the line's contents for the purpose syntaxhighlighting.
To assuage any concerns about opening the door to endless possiblesyntaxes for machine-readable processing of preformatted blocks beingintroduced to Gemtext, I'll retract my previous suggestion of using thetop line for (generic) machine-readable purposes and the bottom line forthe alt text.
The only real machine-readable behavior I want to see in Gemini issource code syntax highlighting anyway, and the spec already supportsand encourages that. In all other cases, alt text (which can clearly beignored or used "at the client's discretion" as per the spec) is justfine on the top line of preformatted blocks. I suppose I don't reallysee 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 aclearer codification in the Gemini spec) of how to use alt text "forcomputer source code to identify the programming language which advancedclients may use for syntax highlighting".
===========================================================================
Here's a simple proposal:
If the first word in a preformatted text block's alt text is the name ofa programming language recognized by the client, then it may (at itsdiscretion) apply syntax highlighting for that language to the block'scontents. =========================================================================== This remains in line with both the spirit and content of Geminispecification Section 5.4.3 Preformatting toggle lines. It alsoexplicitly allows clients to opt-in (or not). Whether or not syntaxhighlighting is applied, the entire alt text line can still be used asperfectly valid human-readable text for accessibility purposes. There is no possibility of a slippery slope happening in the Gemtextspecification because this is just a non-extensible, optional-onlyfeature that is already in the Gemini spec anyway and is just being moreclearly 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: 7BC158EDUse `gpg --search-keys lambdatronic' to find meProtect 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