A proposed scheme for parsing preformatted alt text

[easeout at tilde.team]

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 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.

> 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 user
who depends on alt text for content representation, it's going to be
jarring when some of the time you get code read aloud to you by a screen
reader, or… well, you get what I mean.

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.

Re: machine-parseable tables in Gemtext, I acknowledge that was not
really your point :) But in general I think the discussion around tables
is a symptom of our wish to keep the spec small and not see it slowly
grow forever.

I believe that extensions, when popular enough, become de facto
standards and force the spec to grow more than we might otherwise
prefer, lest the de facto standard simply become the new spec. This
pressure is not necessarily a bad thing, but consider, an accessibility
feature like the human-oriented use of alt text is unlikely to become
popular enough to force its way in by a de facto standard, and would
therefore need the support of the base spec to see acceptance.