💾 Archived View for rawtext.club › ~sloum › geminilist › 002639.gmi captured on 2020-10-31 at 14:40:45. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
A. E. Spencer-Reed easrng at gmail.com
Thu Sep 10 18:26:44 BST 2020
- - - - - - - - - - - - - - - - - - -
What if we use a human readable *and *machine parsable format, somethinglike "This is code in python. It does ..." or "This is a table from/data.csv. It contains information about..." and parse it by usingsomething like /this\s+is\s+(?:an?\s+)?(\S+)\s+(in|of|from)\s+(\S+)\./i Youcan then get structured data like what kind of data it contains while stillpreserving 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>