💾 Archived View for ebc.li › posts › alt-text-proposal.gmi captured on 2020-10-31 at 00:42:27. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
2020-09-07
I just sent out a response to Luke's proposal for alt text on preformatting blocks in the Gemini mailing list. I will also put the entire mail here, for anyone who doesn't follow the mailing list.
A proposed scheme for parsing preformatted alt text
I just had this interesting formating idea reading through this thread:
[modifiers...] [type] [:] <description>
This format lets the alt text be mostly human-readable while keeping some semantics for machines to parse through.
As an example, all these lines should be valid:
"python code: Code to parse this format"
"table: Point leaderboard"
"Description without any machine readable parts"
The [modifiers...] part is a list of adjectives the pre-formatted text has, like a programming language name, type of art (ascii / ansi / unicode / whatever), or whatever else other people can think of. They are all single words separated by spaces.
[type] is the type of the content in the pre-formatted text block. Like "code", "table" or "art"
The [:] is just a separator between the machine-readable part and the description. If a machine reads any ":", it will stop processing, as the continuation of this line is for humans only.
<description> is the human-readable explanation of what's inside the pre-formatted block. It can contain anything, including ":" characters since the machines should stop parsing after the first one.
If a machine has any doubts (any unrecognized modifier or type, or maybe some other heuristic), it should halt parsing and display the entire line as is, to make sure malformed input can still be understood by a human.
I am not entirely sure how well this would actually work "in production", but I feel like this is definitely something to throw out here.
View in the mailing list archives
-- EOF --
CC BY-SA