💾 Archived View for gemini.bunburya.eu › newsgroups › gemini › messages › 1644349376.bystand@zzo38co… captured on 2024-05-26 at 15:23:40. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-04-28)
-=-=-=-=-=-=-
From: news@zzo38computer.org.invalid
Subject: Re: Gemini markup extensions [Was: Re: a solution for emphasis]
Date: Tue, 08 Feb 2022 12:00:44 -0800
Message-ID: <1644349376.bystand@zzo38computer.org>
Daniel Goldsmith <dgold@dgold.invalid> wrote:
Oh, very much this. Using unicode chars is the inverse of what I always
understood to be the purpose of gemini. The use of a "magic string" to denote
a link was specifically chosen to avoid the issue of non-standard characters
having impact on the protocol, your ability to write it, and your ability to
read it.
I really dislike Unicode, anyways.
Having said that, and _pace_ the question of accessibility, I'm coming to the
conclusion that some form of acceptance of the two primary span elements,
<em> and <strong>, need to inform future development in the gemini protocol.
They are necessary for all sorts of reasons (inline quotes, titles of books,
plays, music, for poetry), there is a clear demand for them, they are being
*hacked* into people's capsules no matter what the spec says, and they offer
clear and unambiguous advantages for those using screenreaders.
Yes, there are some advantages, but it results in some extra complexity, and
possible confusion if they are used for something other than formatting. (I
mention below, a possible solution).
(However, I agree this is one deficiency of Gemini format; these are many of
the kind of things which should be wanted in text. Yes, <em> and <strong> are
probably the important ones, and possibly <code> as well, and also footnotes.)
I don't know what shape they should take, but I'd note that newsreaders have
been doing this for a not insignificant period, using essentially the same
characters as markdown.
Whatever they should take, if extensions are made to the format, then I might
suggest to follow the principles (in order to avoid breaking compatibility,
and to ensure that files that have text that would otherwise be confused for
the extended formatting, will still be displayed correctly):
is being used.
ignore unrecognized parameters in the MIME type and treat it like the same
MIME type without the extra parameter.
parameter and files that don't use it MUST NOT have this parameter.
then it SHOULD have an option for the end user to turn on/off this option
regardless of the MIME type of the response.
This is one possible solution; maybe you have other ideas. (Another idea
is a special command inside of the file itself.)
Regardless, the specification must be made clear about how it is working,
and make available reference implementations that you can compare with,
and to confirm that the file is interpreted in the intended way.
(I also have many other ideas, and will try to figure out more details
and then to see what it will be, too.)
--
Don't laugh at the moon when it is day time in France.
Parent:
Start of thread:
a solution for emphasis (by Gustaf Erikson <gerikson@gmial.com> on Sat, 05 Feb 2022 00:13:15 +0100)