💾 Archived View for rawtext.club › ~sloum › geminilist › 005758.gmi captured on 2023-11-14 at 09:52:52. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Adnan Maolood me at adnano.co
Sun Feb 28 21:28:38 GMT 2021
- - - - - - - - - - - - - - - - - - -
Replying here as I never received the original email.
On Sun Feb 28, 2021 at 19:54 GMT, Bradley D. Thornton wrote:
My original suggestion was for a 'convention' that the authors of
clients could find consensus with that will enable the non-sighted
reader to configure that client so as not to render content in between
the preformatted text area of a .gmi file.
That remains my concern. The rest may be worthwhile, or not, but in
either case they involve no changes to the spec.
Whether:
```:
```
or:
```@
```
or:
preformat = "```" [ [WSP] tag ] [ [WSP] alt-text] end-of-line
tag = '@art' / '@code' / '@data' / '@poem'
None of these involve any mention (and again, nor should they) of a
change in the spec.
This entire discussion evolves around what *some* clients *may*
incorporate (by convention) in the form of a configurable option of
their software so that a block of preformatted text can be opted out
from being rendered in the Gemini browser.
I think the following conventions can be adopted instead:
1. Authors of Gemini text are STRONGLY encouraged to add alt text toASCII art and other inacessible preformatted text to prevent it frombeing read aloud by screen readers. For example:
2. Code, poems, and other accessible text SHOULD NOT use alt text andinstead prefer to place any descriptive text above or below thepreformatted text. For example:
Here is a code snippet demonstrating how to use print:```print("Hello, world!")```
3. Clients should allow the user to skip displaying preformatted text.Preformatted text with a non-empty alt text should be consideredinaccessible and should not be displayed. Clients can also assume thatany preformatted text without alt-text is safe to display, but mightwant to allow the user to skip those as well on a case-by-case basis.
This should be easy for gemtext authors and client authors alike.
>
> Are there really any content types besides ASCII art that clients would
>
> need to decide whether to show or not?
>
> Yes. And they are myriad. Consider log dumps, interminable parts lists
> or inventory sheets, perhaps even Microsoft EULAs (because as we all
> know, if you're a living breathing organism, you're already
> non-compliant with their licenses).
I think that in this case the alt-text would probably be better off onits own line. Alternative text is meant to provide an alternativerepresentation for imagery and ASCII art, not for textual content. Userscould still choose to skip the preformatted text if they desire. Forexample:
Server log:```GET /GET /about.gmi(more entries...)```
The client could allow the user to skip displaying the preformattedtext. However, since there is no alt text the preformatted text shouldbe considered accessible, unlike ASCII art.
I believe that this is the simplest and most elegant approach.