💾 Archived View for rawtext.club › ~sloum › geminilist › 005743.gmi captured on 2023-11-14 at 09:53:27. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Luke Emmet luke at marmaladefoo.com
Sun Feb 28 16:28:26 GMT 2021
- - - - - - - - - - - - - - - - - - -
On 28-Feb-2021 15:41, Adnan Maolood wrote:
On Sun Feb 28, 2021 at 10:20 AM EST, Luke Emmet wrote:
I disagree - at present the spec lends equal weight to the two possible
interpretations of the label of the preformatted text areas
- they may be interpreted as an alternative label for screen reader
(an accessibility label since ascii art is meaningless to non-visual
users)
- they may be used for text type identification (to convey the type of
content shown, for syntax highlighting or possibly more useful semantic
purposes, for example a client may choose not to render ascii art at
all)
Currently the specification only allows for specifying the language for
computer source code, not for identifying the type of text. So this
would mean expanding the scope of the specification, not restricting it.
I am not really in favor of this.
To specify the language used in this context is effectively to identify the type of text. I cannot believe the specification was literally only talking about programming languages in this respect, although that is an example.
The spec does not restrict to a single application or interpretation of
the label for these preformatted areas. Both elements are important.
It is a reduction in scope to turn the may to a must as you suggest.
From an accessibility point of view, you could say that indicating the
content type is actually more important to screen readers as they can
definitively use that to choose whether to show the content or not.
Are both elements *really* important?Well both were considered to be valid applications of the preformatted label in the spec.
You might as well ask if I send you a document, is it more important to know the media type or the title?
Are there really any content types besides ASCII art that clients would
need to decide whether to show or not?If I was a non-technical person I might very well want not to see source code, or to have them "behind a button", at the same time I might like to see everyone's ascii art or poetry. These are legitimate preferences to be configured into a client.
On the list recently there was a discussion about rendering mathematics in gemini. With an appropriate content label an aware client could display these in an attractive rendered form.
- Code can be read as-is. I believe that syntax highlighting is not
really necessary. The language used for the code can be inferred by a
human from the surrounding text, or the author can write a small
sentence underneath each preformatted code block describing the code.That could equally be true for ascii art. Put some text around it to describe it then use a definitive content type label to indicate what type of text it is? Then use the type label to definitively decide not to show the art to a non visual user.
- Poems can be read as-is, so should not have any alt text.
- Tables probably do not belong in Gemini text.
In my opinion designating the content type is not really necessary for
the above examples. It is much simpler to treat the presence of alt-text
as an indicator that the preformatted text is not accessible.The presence of a label on the text area is not definitive of what content it contains, so its absence or existence can't completely determine whether or not it should be rendered. It is an over interpretation of the label's existence.
- Luke