💾 Archived View for rawtext.club › ~sloum › geminilist › 002590.gmi captured on 2020-10-31 at 14:38:46. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
easeout at tilde.team easeout at tilde.team
Mon Sep 7 19:16:10 BST 2020
- - - - - - - - - - - - - - - - - - -
On Mon, Sep 07, 2020 at 05:36:08PM +0100, Luke Emmet wrote:
On 07-Sep-2020 10:06, Kevin Sangeelee wrote:
Anything that adds text that's really only parseable by a machine is
just a teeny bit user-hostile.
Well the alt-text never gets shown to the user, it is invisible to them.
Some clients might act on it (for example at the moment to show a tool tip).
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 alttext in HTML <img>. That is, to be an alternative representation of thecontent, like "Photograph of a woman on a horse". In that sense it ismeant to be text that users see! Just not every user in allcircumstances. HTML <img> alt text is meant in part for users that usescreen readers, but users nonetheless. So I would prefer we not goadding extensions to alt text that prevent it from being alwayshuman-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 inGitHub-flavored Markdown you can write ```typescript to get TypeScriptsyntax highlighting. While not an alternative content representation,that is at least human-readable.
My personal view is that the CSS style delimiters attribute1: value; is less
hostile than others. So it was part of the design consideration. Those
clients or users wanting a simple experience can just ignore it all anyway.
I agree it's less hostile than other possibilities, but if you're a userwho depends on alt text for content representation, it's going to bejarring when some of the time you get code read aloud to you by a screenreader, or… well, you get what I mean.
Really, I think what we have here is a field with two possible uses thatare at cross purposes, one for people and one for machines. Syntaticallyit's based on something in Markdown that's for machine use, but it'srecommended for the human use. But the whole idea of it being for humanuse is spoiled by the fact that it will grate on humans in cases when itis not for their use.
I would rather the spec either make a call and pick one purpose, or omitthe field entirely, rather than leaving this conflict unresolved.
Re: machine-parseable tables in Gemtext, I acknowledge that was notreally your point :) But in general I think the discussion around tablesis a symptom of our wish to keep the spec small and not see it slowlygrow forever.
I believe that extensions, when popular enough, become de factostandards and force the spec to grow more than we might otherwiseprefer, lest the de facto standard simply become the new spec. Thispressure is not necessarily a bad thing, but consider, an accessibilityfeature like the human-oriented use of alt text is unlikely to becomepopular enough to force its way in by a de facto standard, and wouldtherefore need the support of the base spec to see acceptance.