Cognitive aspects of navigation in gemini space

[Brian Evans]

Ivy writes:
> I like the idea of severely limiting the available block-type options.
>
> How about this for block syntax, with the understanding that the alt
> text is highly recommended for accessibility. Specifying the block
> type and the programming language or written language (as appropriate)
> would be strictly optional: those that wanted to make use of them
> could, those who did not want to make use of them would not have to.
>
> For the purposes of this proposal, there would be *no space* between
> the backticks and the optional content-type field, which field may not
> contain spaces. There must be at least one space on the line before
> the (recommended) alt text. That way, the client doesn't need to try
> and figure out where one ends and one begins: the instant the client
> sees a space, we're into alt-text territory for the rest of the line.
>
> ```[art | code[:programming language] | text[:written language]] [alt text]
> ...
> ```

I think you hit on it perfectly Ivy. I love this proposal and it definitely has my full support.
It communicates a lot of information in a small space and is still very parsable. Given the
specs mandate of the ``` not being shown directly tot he user it should not clutter up
the document for those viewing it under most circumstances. It is also easy to write for
those developing content. I like that both parts are optional, but available, and a lot can
be communicated with them. Well done.

-- 
Sent with https://mailfence.com
Secure and private email