Cognitive aspects of navigation in gemini space

[Brian Evans]

_jan6 writes:_
> I'm not a fan of the ending part having text too,
> slightly harder parser, and noticeably harder to read for humans, 
> especially if there are several blocks back-to-back

I'm not sure about this. It seems to me that someone parsing by line can just set a flag for `in_pre_block`.
When they get to a line beginning with ``` they know the pre block has ended. Sounds dead simple to me.

As to harder for humans, the whole point is to make it easier for humans. The ``` and text should not appear
to most users. It is not for them, it is for the client. Having the opening ``` with a type of some form allows a
client to offer options such as "show ascii art" and "show pre text" as boolean options. If someone chose to
set "show ascii art" to to false for the below:

``` art
:-)
``` A simple smiley

The client could display:

[art: A simple smiley]

To that user instead of the full block. I think there is real value and utility in that. Not only that but it adds to
the ability of any future screen reader implementations to be able to parse the document in a way that will
make sense to the user using the screen reader.

I would go so far as to recommend this be a requirement for preformatted blocks in accessibility merits alone.
I think there should be three types: Art, Text, Code and that descriptions on the end blocks should be compulsory.

That said, I'm definitely not wanting to bikeshed this thing and we have already had a lot of text/gemini discussions
in the past.

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