💾 Archived View for rawtext.club › ~sloum › geminilist › 005795.gmi captured on 2023-09-08 at 17:12:59. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Caolan McMahon caolan at caolan.uk
Mon Mar 1 10:12:18 GMT 2021
- - - - - - - - - - - - - - - - - - -
My suggestion would be to place type information after the opening ```, and
alt-text after the closing ```, for the following reasons:
Existing documents that use alt text as per the current spec will be
broken. Existing clients which MUST ignore any text following the
terminating ``` won't be able to access the alt text on new documents
following this suggestion. Seems like we'd be getting the worst of
both worlds.
From a backwards compatibility perspective, yes, I agree. Alt text was allowed after the initial ``` so we are probably stuck with it.
How is the type more useful for accessibility than a general
description of its content? Would knowing in an art gallery whether
you're standing in front of an oil painting or an aquarelle be more
useful than knowing what the painting depicts?
No, but knowing whether the picture contained text or art would tell you whether to use assistive technology to read it or describe it.
It seems most the disagreement here is whether the client should automatically make some sensible choices for the user (content type first), or the user should process the alt text and make their own call (alt text first)?
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.
A solution to a problem of its own making.
Sorry, I don't follow this point.