💾 Archived View for rawtext.club › ~sloum › geminilist › 000758.gmi captured on 2020-09-24 at 02:21:15. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
James Tomasino tomasino at lavabit.com
Sun May 17 14:16:05 BST 2020
- - - - - - - - - - - - - - - - - - - ``` On 5/17/20 11:42 AM, jan6 at tilde.ninja wrote: > I'm not a fan of the ending part having text too, > slightly harder parser, and noticeably harder to read for humans, > especially if there are several blocks back-to-back > other than that, not too bad idea, I suppose TLDR;
--- The long version --- I've been thinking of ways to keep it extremely simple. If the goals are: - provide alt text for a block that may not be easily parsed by bots &screen readers - indicate which blocks should and should not be parsed Then I think we can accomplish the goal with a single code fence suffixthat is either blank, indicating that the content CAN be parsed, or hastext, indicating that IS the alt text.
That would be incredibly easy to parse and require zero effort fromclients that already exist since they can continue to just look at thefirst three characters and ignore the rest. Search engines can read thealt/descriptor and skip the rest of the block if it exits, or read thecontents if its blank. Easy all around. The complication would come if you want that space to have anotherpurpose, such as defining the language for syntax highlighting on a codeblock like we see in markdown.
This would be interpreted for alt-text purposes as just "bash". First ofall, it would mean that search engines wouldn't parse code blocks whichmay or may not be a bad thing.
It may actually work out great for accessible clients though. I don'tknow of anyone making an accessible client YET, but if it werestructured this way the block, when hit, could indicate verbally that apreformatted block had been reached and the alt/descriptor could beread. A good accessible client might even inform the user how many linesthe block contains and offer some way to "page" through it bit by bit.
This sort of behavior would be nice to talk through with anyone workingon such a client, but beyond giving it some initial consideration Idon't see it as belonging in the gemini spec itself.