<-- back to the mailing list

SPOOFED: Cognitive aspects of navigation in gemini space

Nicole Mazzuca nicole at strega-nil.co

Sun May 17 20:36:37 BST 2020

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

That seems like a mistake. Code highlighting is _really_ important for code gemlogs, imo.

Nicole

Sent from ProtonMail mobile

-------- Original Message --------On May 17, 2020, 12:28, James Tomasino wrote:

> 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 no
> special "type" at all. Just
>
> ```[optional whitespace][optional alt text]
>
> The art type is meaningless once we have an alt, so that's easy to
> dismiss. The text type doesn't help tell me if the content should be
> spidered or read aloud. Including a language property seems nice, but we
> don't have a lang property on the whole document, so it's overkill in
> this context.
>
> Really the only thing we're doing is codifying a bunch of extra rules
> and enumeration so that we can specify code syntax languages. That leads
> to clients being able to mark things up, which is fine and all, but
> seems far less important than the plain accessibily goal.
>
> If this becomes cumbersome or fragile (space vs no space breaking
> things) then people won't use it. I suggest the simpler approach here
> will 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 it
> gets put into practice, clients can check for it if it matters to them.-------------- next part --------------An HTML attachment was scrubbed...URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200517/d49f44e0/attachment.htm>