Luke Emmet luke at marmaladefoo.com
Mon Sep 7 20:31:58 BST 2020
- - - - - - - - - - - - - - - - - - -
On 07-Sep-2020 19:16, easeout at tilde.team wrote:
I think it would be helpful to quote the spec here:
Use of alt text is at the client's discretion, and simple clients may
ignore it. Alt text is recommended for ASCII art or similar
non-textual content which, for example, cannot be meaningfully
understood when rendered through a screen reader or usefully indexed
by a search engine. Alt text may also be used for computer source code
to identify the programming language which advanced clients may use
for syntax highlighting.
Alt text is recommended for, and I think named after, the role of alt
text in HTML<img>. That is, to be an alternative representation of the
content, like "Photograph of a woman on a horse". In that sense it is
meant to be text that users see! Just not every user in all
circumstances. HTML<img> alt text is meant in part for users that use
screen readers, but users nonetheless. So I would prefer we not go
adding extensions to alt text that prevent it from being always
human-readable.
(Refer to the alt attribute as documented here:)
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Img
The advanced use case cited in the spec matches the way in
GitHub-flavored Markdown you can write ```typescript to get TypeScript
syntax highlighting. While not an alternative content representation,
that is at least human-readable.
Whilst a reference to the HTML spec is interesting, we are defining Gemini here, so the Gemini spec isn't beholden to HTML.
The spec mentions both applications of the tail of the "mode switch line" (to avoid a normative gloss), both as an alt text and to identify the programming language. So this duality is already envisaged in the spec.
Really, I think what we have here is a field with two possible uses that
are at cross purposes, one for people and one for machines. Syntatically
it's based on something in Markdown that's for machine use, but it's
recommended for the human use. But the whole idea of it being for human
use is spoiled by the fact that it will grate on humans in cases when it
is not for their use.
I would rather the spec either make a call and pick one purpose, or omit
the field entirely, rather than leaving this conflict unresolved.
I prefer that the spec allows for multiple uses. Primarily it is a label for human benefit, but that is not to say it cannot be comprehended by a machine.
This sort of relates to the other thread on the ML right now - about whether there could be a feed format based on gemtext - it would be based on certain conventions in the use of the format, without breaking gemtext at all.
I don't see how the spec can mandate the content that is in an informative part of the content -i.e. a label on an element.
Best wishes
- Luke