A proposed scheme for parsing preformatted alt text

[Kevin Sangeelee]

Since my services have been retained by the Devil himself, I am obliged to
advocate on his behalf as follows:

Anything that adds text that's really only parseable by a machine is just a
teeny bit user-hostile.

The ideas being discussed go further, because (unless I misunderstand) it
encourages text in weird unaligned formats to be served up by default.

I would argue (on behalf of the Devil, of course) that mono-spaced
preformatted text is already perfect for aligning user-readable tables.
It's just awkward for machines to process semantically. There are however
reasonably reliable heuristics to figure out columns, should the client
want to add decoration. etc.

Perhaps the alt-text could be used to specify something like 'source:
/data/my_original.csv', to give a person-readable route to machine-readable
data that the client could use to fetch and render in-place on behalf of
the user.

Kevin

On Mon, 7 Sep 2020 at 00:21, Luke Emmet <luke at marmaladefoo.com> wrote:

> Hi All
>
> We had an interesting discussion on the #Gemini IRC channel earlier
> today about a generalised scheme for parsing the alt text on
> preformatted regions, e.g.
>
> ```this is the alt text, not normally displayed to the end user
> the preformatted content
> ```
>
> It was a collective discussion, but I've written up some of the key
> points in a post here:
>
> gemini://
> gemini.marmaladefoo.com/blog/7-Sep-2020_Parsing_preformatted_alt_text.gmi
>
> Essentially the key design considerations are as follows:
>
> 1. By default the whole alt text can be used as a label (current behaviour)
> 2. Use CSS style syntax for the remainder, a familiar and low ritual syntax
> 3. Don't prescribe the attributes, allow practice to suggest them
> 4. Be backwards compatible and friendly to screen readers etc.
>
> two initial attributes seem to have obvious initial utility and could be
> used to effectively label content in a practical way:
>
> content-type
> lang
>
> Best Wishes
>
>   - Luke
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200907/073f5115/attachment.htm>