💾 Archived View for rawtext.club › ~sloum › geminilist › 005755.gmi captured on 2021-11-30 at 19:37:34. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Luke Emmet luke at marmaladefoo.com
Sun Feb 28 20:41:05 GMT 2021
- - - - - - - - - - - - - - - - - - -
On 28-Feb-2021 14:32, Caolan McMahon 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.
Ideally, the two would be separate. 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.I think this is a sensible way to disentangle these two concerns that are covered by the spec. At present these two aspects are merged together which means it is hard to write any client code to reliably provide any UI to assist the user beyond all or nothing, or a text label.
We had some discussion on this list a while back on some of this, and it seems making use of the opening and closing marker was already proposed by Sean Conner
https://lists.orbitalfox.eu/archives/gemini/2020/002671.html
linking on to:
gemini://gemini.conman.org/test/preformat.gemini
and
gemini://gemini.conman.org/test/preformat-2.gemini
My suggestion would be to place type information after the opening ```, and alt-text after the closing ```, for the following reasons:
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.
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.
Something very close to this was the scheme proposed by Sean in the preformat-2 example:
I don't have a strong view on which should be used for the top and which for the bottom, I'd just be glad to see the roles clearly separated to support both use cases presented in the spec.
From a parsing point of view I see the benefits in putting the text type first as you indicate. There is an argument perhaps to put the alt text first which is perhaps that so far the use of this label is mostly free form so legacy content would map better to the human alt text accessibility label.
For now, I have no opinion on the format of content type labels.Given the label is of a text area, we could simply say one can use any "sub type" of text media type, so a single word would be text/*
javascript (means text/javascript)csv (means text/csv)lua (means text/lua)
and so on. This would be my preference.
Or optionally provide a proper media type if you want (e.g. application/atom+xml)
 - Luke