💾 Archived View for rawtext.club › ~sloum › geminilist › 000778.gmi captured on 2020-09-24 at 02:20:28. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
James Tomasino tomasino at lavabit.com
Sun May 17 20:28:18 BST 2020
- - - - - - - - - - - - - - - - - - - ``` On 5/17/20 6:43 PM, jan6 at tilde.ninja wrote: > nothing is preventing me from making an alt-text saying something like "this | that - a poem", so it wouldn't exactly solve anything, other than making it slightly easier to parse (separating only on first space shouldn't be hard at all anyway) I'm really leaning toward the simplest of all things, which is nospecial "type" at all. Just
The art type is meaningless once we have an alt, so that's easy todismiss. The text type doesn't help tell me if the content should bespidered or read aloud. Including a language property seems nice, but wedon't have a lang property on the whole document, so it's overkill inthis context.
Really the only thing we're doing is codifying a bunch of extra rulesand enumeration so that we can specify code syntax languages. That leadsto clients being able to mark things up, which is fine and all, butseems far less important than the plain accessibily goal.
If this becomes cumbersome or fragile (space vs no space breakingthings) then people won't use it. I suggest the simpler approach herewill be better for gemini.
If people want to use the alt text area to indicate code & language,then that's a pattern we can toss into the best practices doc. If itgets put into practice, clients can check for it if it matters to them.