easeout at tilde.team easeout at tilde.team
Mon Sep 7 21:31:34 BST 2020
- - - - - - - - - - - - - - - - - - -
On Mon, Sep 07, 2020 at 08:31:58PM +0100, Luke Emmet wrote:
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.
To be clear, I'm not saying we are beholden to HTML. But it is the basisfor the spec's vocabulary: In this case "alt text" is a term from HTML.I'm pointing to HTML's <img> alt attribute because that's what I believeSolderpunk was talking about when the spec mentioned "alt text". I thinkthat, and the text of the spec ("Alt text is recommended for…"), supportthe notion that human-readable alternative content representation is theprimary point of the field.
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.
It does, but my next point was that this two-uses-for-one-fieldsituation creates conflict between the uses with negative consequencesfor users. It would be better regarded as a mistake in the spec worthamending.
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.
I hear you, but I don't see how that addresses the problem create forusers by having the field work two ways.
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.
As I understand it, a feed format based on Gemtext would be usable as aplain Gemtext page by a plain browser, which is great. And for a feedaggregator to use it as a subscription mechanism, you'd have toformalize some piece of it. All of that sounds OK for that purpose.
But in this thread, I think we're talking interpreting Gemtext alt textdifferently, not for a special kind of client, but in regularuser-facing interactive browsers. And not on special documents likefeeds, but in general purpose Gemtext pages.
I think that difference makes these two cases not comparable. AddingGemtext-compatible formality for feed pages has no effect on otherGemtext pages. Adding accessibility-incompatible formality for allGemtext pages could have a negative effect on particular users acrossGemini as a whole.
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.
I think what the spec can do is make a clearer recommendation. Maybewe'd have two fields and they wouldn't have to step on each other'stoes.