A proposed scheme for parsing preformatted alt text

easeout at tilde.team easeout at tilde.team
Sat Sep 12 00:23:13 BST 2020


On Thu, Sep 10, 2020 at 10:31:51PM -0700, Meff wrote:
> (Apologies for the double email Sean, I forgot to Reply All)
> 
> Sean Conner <sean at conman.org> writes:
> 
> >   And back in the mid-90s, there *were* plenty of web clients.  Easily a
> > dozen that were easily available and that was back in time when it was easy
> > enough to parse HTML, there was no CSS and no Javascript, and it was
> > conceivable that someone could write a simple web browser in a weekend [1].
> >
> >   Then Sandra Snan sent the following link:
> >
> > 	https://drewdevault.com/2020/03/18/Reckless-limitless-scope.html
> >
> > Wherein it's mentioned that the current "state of the web" is described by
> > 114,000,000 words spread across 1,217 standards documents.  You get here by
> > incremental changes, all of which are "easy" and "it would be so
> > nice."
> 
> I agree with this. I understand that there's a couple points here that
> the alt-text discussion is trying to solve:
> 
> * Formatting hints for non-human clients
> ** Specifically this benefits users that may be visually impaired and
>    their use of tools such as screen readers
> * Hints or descriptions for human readers
> 
> I don't see a way out of this without making Gemtext much more
> complicated than it is now.

Here are a few options that avoid complicating Gemtext.

1. Use alt text only as an accessible content description for humans.
   (not a tooltip or caption)
2. Use alt text only as a formatting hint for machine use. Rename it.
3. Get rid of alt text entirely.

All of these options attempt to solve the problem that alt text
currently has multiple uses and would not be reliable to a user who
needed it for a particular use. Any of these options would mean altering
the spec. I like option 1 best.

The reason I didn't mind syntax-on-top, alt-on-bottom was that it solved
the problem of one field with multiple uses, by making them two fields.
However it would complicate Gemtext and I agree we don't need to
do that.


More information about the Gemini mailing list