A proposed scheme for parsing preformatted alt text

[A. E. Spencer-Reed]

What if we use a human readable *and *machine parsable format, something
like "This is code in python. It does ..." or "This is a table from
/data.csv. It contains information about..." and parse it by using
something like /this\s+is\s+(?:an?\s+)?(\S+)\s+(in|of|from)\s+(\S+)\./i You
can then get structured data like what kind of data it contains while still
preserving it's use for assistive technologies.

On Thu, Sep 10, 2020 at 12:43 PM Gary Johnson <lambdatronic at disroot.org>
wrote:

> Just to throw another idea out there:
>
> There has been some extended discussion now on the mailing list about a
> conflict in machine-readable vs human-readable content being added after
> the opening pre-formatting ``` characters. It seems that enough people
> in the Gemini community see both of these kinds of information as
> providing value, but the spec currently lacks a clear path forward for
> differentiating between them.
>
> Right now, anything written after the closing pre-formatting ``` chars
> isn't being used as per the spec's instructions. I can't help but wonder
> what would happen if we were able to put machine-readable instructions
> (like "table", "image", "code:python") on the opening line (so that
> clients could switch their line interpreter modes accordingly) and place
> human-readable alt text (mainly for screen readers) on the closing line
> (assuming the screen reader will probably just skip over the
> pre-formatted block's contents anyway and then read the alt text if
> provided).
>
> I realize this would entail a fairly significant change to the spec, but
> it seems - at least to me - to resolve the issue in a rather
> straightforward fashion. If I'm missing something important here, please
> let me know. I'm also interested in hearing anyone else's suggestions
> for how to address this issue.
>
> Onward Geminauts!
>   Gary
>
>
> mbays at sdf.org writes:
>
> > * Wednesday, 2020-09-09 at 22:41 +0100 - Luke Emmet <
> luke at marmaladefoo.com>:
> >
> >> On 09-Sep-2020 18:38, mbays at sdf.org wrote:
> >>> So, with apologies for hijacking this thread with something totally
> >>> opposed to its original idea, I'd like to encourage client authors
> >>> to close this extensibility hole by not suppressing text after the
> >>> "```" in preformatting toggle lines.
> >> As far as I can see, the spec seems clear enough on this: "5.4.3:
> >> Any line whose first three characters are "```" (i.e. three
> >> consecutive back ticks with no leading whitespace) are preformatted
> >> toggle lines. These lines should NOT be included in the rendered
> >> output shown to the user."
> >
> > That passage predates the later additions to the spec in the same
> > section about what to do with text on these lines. I guess the
> > intention was to make it clear that clients aren't expected to
> > actually print "```". I don't think it should be read as ruling out
> > printing the alt text.
>
>
> --
> GPG Key ID: 7BC158ED
> Use `gpg --search-keys lambdatronic' to find me
> Protect yourself from surveillance: https://emailselfdefense.fsf.org
> =======================================================================
> ()  ascii ribbon campaign - against html e-mail
> /\  www.asciiribbon.org   - against proprietary attachments
>
> Please avoid sending me MS-Office attachments.
> See http://www.gnu.org/philosophy/no-word-attachments.html
>


-- 
🍵 <https://www.google.com/teapot>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200910/ffa376ac/attachment.htm>