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
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
gemini://gemi.dev/gemini-mailing-list/messages/002671.gmi
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
--- => 005732.gmi Previous in thread (1 of 26): 🗣️ Caolan McMahon (caolan (a) caolan.uk) => 005765.gmi Next in thread (3 of 26): 🗣️ Oliver Simmons (oliversimmo (a) gmail.com) => ../000761.gmi View entire thread.