💾 Archived View for rawtext.club › ~sloum › geminilist › 005765.gmi captured on 2024-03-21 at 16:37:54. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2021-11-30)

-=-=-=-=-=-=-

<-- back to the mailing list

Alt text and media types for preformatted text

Oliver Simmons oliversimmo at gmail.com

Sun Feb 28 22:57:48 GMT 2021

- - - - - - - - - - - - - - - - - - - 

On Sun, 28 Feb 2021, 14:32 Caolan McMahon, <caolan at caolan.uk> wrote:

Hello all,
This is in response to the various alt-text / content type suggestions
floating around.
I'm uncomfortable with inventing a new syntax to combine these two pieces
of data for two reasons. First, new syntax complicates the spec. Second,
any ambiguity will reduce the usefulness both to a client.

The spec dosent have any sytax as of current, it's free form text.Adding syntax to it it would only remove ambiguity.

Ideally, the two would be separate.

+1

Most suggestions I've seen so far were to follow the opening ``` of a

preformatted block with a mix of this data. However, there is also the
option of adding data after the closing ``` marker, keeping the two
separate.
My suggestion would be to place type information after the opening ```,
and alt-text after the closing ```, for the following reasons:

Gemtext is designed so it can be read line-by-line, top-to-bottom and becompletely understood.Sticking text after the closing ``` that affects content would break this -I presume that's why it's explicitly disallowed in the spec.

1. Even for accessibility, I suspect knowing the content type is more

practically useful to the client in the majority of existing cases. Most
ASCII art is purely decoration, and knowing the content type is
text/x-ascii (or similar) upfront is important so the screen reader can
simply skip it.

2. Knowing the content type upfront would allow clients to present

streaming data correctly using appropriate colours and escape codes for
code highlighting, for example.

Code highlighting is a good use case for this - but it would also ~sortaallow for putting other content inline if we aren't careful on what'sallowed.

3. Placing the content type after the opening ``` line is familar to

markdown authors, which is not a reason in itself, but a welcome bonus
nonetheless.
4. Placing the alt text after the closing ```, at the end of the
preformatted block has a nice symmetry with links which place the
human-friendly text at the end too.

I like the ordering of content type first and alt text last, as Gemtextworks line-by-line top-to-bottom, knowing the content type first is good,as it may affect following stuff.

But I think using the opening/closing toggles like this may causeconfusion, if you look at the line in isolation, you can't tell what thetext following it is. You're supposed to be able to tell how a line wouldbe structured/it's meaning by only looking at the first three lines.

-Oliver Simmons-------------- next part --------------An HTML attachment was scrubbed...URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210228/ab749c09/attachment.htm>