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 basis
for 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 believe
Solderpunk was talking about when the spec mentioned "alt text". I think
that, and the text of the spec ("Alt text is recommended for?"), support
the notion that human-readable alternative content representation is the
primary 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-field
situation creates conflict between the uses with negative consequences
for users. It would be better regarded as a mistake in the spec worth
amending.
> > 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 for
users 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 a
plain Gemtext page by a plain browser, which is great. And for a feed
aggregator to use it as a subscription mechanism, you'd have to
formalize some piece of it. All of that sounds OK for that purpose.
But in this thread, I think we're talking interpreting Gemtext alt text
differently, not for a special kind of client, but in regular
user-facing interactive browsers. And not on special documents like
feeds, but in general purpose Gemtext pages.
I think that difference makes these two cases not comparable. Adding
Gemtext-compatible formality for feed pages has no effect on other
Gemtext pages. Adding accessibility-incompatible formality for all
Gemtext pages could have a negative effect on particular users across
Gemini 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. Maybe
we'd have two fields and they wouldn't have to step on each other's
toes.
---
Previous in thread (9 of 50): 🗣️ Sandra Snan (sandra.snan (a) idiomdrottning.org)
Next in thread (11 of 50): 🗣️ Sean Conner (sean (a) conman.org)