Alt text and media types for preformatted text

Luke Emmet luke at
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

linking on to:



> 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. 

  - Luke

More information about the Gemini mailing list