A proposed scheme for parsing preformatted alt text

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

---

Previous in thread (19 of 50): 🗣️ Alex // nytpu (alex (a) nytpu.com)

Next in thread (21 of 50): 🗣️ A. E. Spencer-Reed (easrng (a) gmail.com)

View entire thread.