A proposed scheme for parsing preformatted alt text

[Luke Emmet]

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