💾 Archived View for rawtext.club › ~sloum › geminilist › 000774.gmi captured on 2020-11-07 at 01:45:18. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2020-09-24)

-=-=-=-=-=-=-

<-- back to the mailing list

SPOOFED: Cognitive aspects of navigation in gemini space

jan6 at tilde.ninja jan6 at tilde.ninja

Sun May 17 19:36:58 BST 2020

- - - - - - - - - - - - - - - - - - - ```

May 17, 2020 9:15 PM, "Katarina Eriksson" <gmym at coopdot.com> wrote:
> 
> Both are OK according to the proposal above, there is no "must" as everything is optional
> everything except the space, is ;Pin order for the space to be optional it'd need to be [art|blabla][ alt] instead of [art|blabla] [alt], as latter makes it mandatory to have a space there no matter what (and a single space at that, not allowing tabs or multiple spaces)

I'm not sure having types which are optional, is too good of an idea, but otherwise it's nice...what if I happen to have an alt text like "code red" on some art piece? accessible clients would read nonsense...

also don't really see the point/reasoning of the "text" type there, if it's not code nor art, what is it?monospace text for no reason? maybe just "misc" category then? accessibility-wise you can just avoid art, so that doesn't seem to be much reason for a text type...

also maybe allow one-letter shorthand types? kinda like [a[rt]|c[ode]|t[ext]], use either "c hello.lua" or "code hello.lua"not much practical value, but it allows one to only check the first character and skip to alt-text, if wanted (or ignore anything other than first 4 characters on that line)