💾 Archived View for rawtext.club › ~sloum › geminilist › 005704.gmi captured on 2023-11-14 at 09:55:04. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Bradley D. Thornton Bradley at NorthTech.US
Fri Feb 26 15:13:32 GMT 2021
- - - - - - - - - - - - - - - - - - -
On 2/25/2021 6:51 PM, Sean Conner wrote:
It was thus said that the Great Rohan Kumar once stated:
On Thu, Feb 25, 2021 at 05:25:08PM -0500, Sean Conner wrote:
I might suggest something like:
preformat = "```" [ [WSP] tag ] [ [WSP] alt-text] end-of-line
tag = '@art' / '@code' / '@data' / '@poem'
I think that a small but significant change to the spec is necessary
here. My proposal:
I also saw somewhere in this thread someone suggest something that wouldenable the server to dictate the delivery of how the content ispresented. I'm definitely NOT in favor of something that requiresclients to format text a certain way based on what a server says, andfurther, such is contrary to the design philosophies of Gemini goingback as far as discussions in June 2019 before the first line of codewas ever written by anyone.
The proposal above does not require a change in the specification for
text/gemini, and could be considered a convention used.
Indeed. And this is an elegant solution.
It is, however, from the perspective of a developer, and as I certainlyadmire its utility and I have no real issues with something like this,I'm also thinking about the majority of people writing gemlogs. It isasking a bit (of optional syntax) that expects an author of a page aswell as the author of a client to incorporate.
Where this may be an ideal situation, my original intent wasn't tosuggest any particular handlers, but rather, a simple convention that*some* authors of clients could key off of in the text, who are wantingto facilitate "Accessibility" for non-sighted readers.
Perhaps there are more comprehensive aspects that are beyond what I wasattempting to address for avoiding the spamnation of non-sightedreaders... So I don't really have a real preference, other than to saywhatever it is, that it be simple for someone writing a page and easyfor authors of *some* clients to accommodate.
- Three backticks signify readable preformatted text (e.g. a code
snippet or a poem); screen-readers should not skip this.
- Four backticks signify something that isn't readable, like ascii-art.
I think this was a suggestion to alter the spec. As such I feel it's notnecessary to consider as such. What I suggested, indeed implemented, wasa way for a client to interpret something that follows as something thata non-sighted reader would rather not have to endure.
I believe it was Solene that brought up the obvious, that '```' and'````' are prone to issues. When I read what she wrote, I thought aboutusing a colon (:) instead, very unobtrusive for a key that could alert*some* clients to not deliver what is contained in the block, whilekeeping the readability of the raw .gmi file.
Where actual code is concerned, I think that what Sean proposed isprobably the most effective, and still by convention, not any specchanges, but it "might" add a lot of weight to *some* clients that seekto provide syntax highlighting.
Where poetry is concerned, I fail to see the significance at all. It's ablock of preformatted text, right? Am I missing something? Coz I fail tosee the significance between prose and poetry where preformatted text isconcerned. It certainly has no significance where accessibility isconcerned, IMO, since non-sighted readers would probably want to listento the poems anyway, albeit, with a really messed up cadence ;)
Just imagine yourself, surfing Gemini space, and having to listen to this:
<snip
.-. ( ( `-'
. ,- To the Moon Alice ! .'. |o| .'o'. |.-.| ' ' ( ) ) ( )
____ .-'""p 8o""`-. .-'8888P'Y.`Y[ ' `-. ,']88888b.J8oo_ '`. ,' ,88888888888[" Y`. / 8888888888P Y8\ / Y8888888P' ]88\: `Y88' P `888:: Y8.oP '-
Y88:| `Yb __ `'|: `'d8888bo. :: d88888888ooo. ; \ Y88888888888P / \ `Y88888888P / `. d88888P' ,' `. 888PP' ,' `-. d8P' ,-' -CJ- `-.,,_'__,,.-'</snip>
I picked a format that should be easy to find, with a limited set of
options that, in my opinion, seem to cover the majority of cases with
preforamtted blocks. Again with some examples, only with alt-text and NOT
with my proposal:
```: No text is required at all to let an accessible client opt to skip this
____ _ _
| _ \ _ _| |_| |__ ___ _ __
| |_) | | | | _| '_ \ / _ \| ._ \
| __/| |_| | |_| | | | (_) | | | |
|_| \_, |\__|_| |_|\___/|_| |_|
|___/
```
The following is beyond the scope of my immediate concern for agreedupon convention by the authors of clients to enable user accessibilityfor non-sighted readers. I think that here is where what Sean hasproposed comes into its own and demonstrates some real value, and, as hepoints out changes nothing in the spec - but it does ask a bit of theauthors of Gemini clients who wish to enrich the presentation of syntax.
``` Python
@app.route('/')
def index[]:
try:
session['num']
except:
session['success'] = False
session['num'] = random.randrager(1,100)
return render_template('index.html')
```
This next example from Sean I want to address in more detail, so I'll dothat following the example.
``` Python
Genus #species common name
-------------------------------------------
Antaresia 4 Children's phythons
Apodora 1 Papaun olive python
Aspidites 2 Sheild pythons
Bothrochilus 1 Bismark ringed python
Liasis 3 water pythons
```
Okay Solene and I discussed something related to the above off listbriefly, and it is really on a different topic altogether, but I mightas well bring it up here because I keep seeing people asking for changesto the spec to accommodate more markdown features, which is IMO,problematic.
I mentioned to Solene that I thought it would be nice if more featuresof Markdown were supported in clients, but that doesn't mean that it hasany business being in the Gemini specification.
Why? Because Markdown for the most part is perfectly readable even if itisn't rendered as such (Even pretty much tables with cells, etc.).
So my use case is writing papers like showcased above with Genus andSpecies like, **Flabellina iodinea** or **Cordyceps sinensis** or**Pleurotus ostreatus** - Scientific convention is such that one shoulditalicize or underline genus and species. Now, markdown makes that niceand easy, but most everyone already knows how to interpet "*" or "**" or"***" or their underbar equivalents and it does nothing to detract fromthe readability of the text even if it isn't rendered as bold, orunderlined, or in italics.
The one thing that I would like to see support for in clients, is theinline preformatted text begin and end markers:i.e., `$ rm -f /bin/laden`. But absolutely NONE of these things requirenor beg for inclusion into the Gemini spec, yet they *could* besupported in *some* clients.
I hope that puts those discussions for the expanded use of markdown tobe included in the spec, at least for the next fortnight :)
I think that '@poem', '@art', '@code' and '@data' would be very helpful to
a client program. Adding an additional backtick for "something that isn't
readble" just seems too little.
But anyone arguing for (or against) this, please feel free to use the
above Python examples when making arguments.
Yes, thank you for making those exammples handy :)
This is consistent with the spirit of gemtext: characters at the
beginning of a line are the only way to describe semantics.
Indeed.
Solene also mentioned her aprehensions in using a particular languagefor such tags, which I thought was very eloquently addressed byStephanie below:
<snip
OK, inspired by my past life as a Perl programmer, I suggest a fullyi18n solution:
</snip > I really like this too! Notwithstanding my questions as to why poetrywould be relevant, and the only thing I would mention would be that Idon't actually care for the "@" sign, for to me, it usually impliesother meanings, although I get the association it may have for ASCII. Iwould prefer rather, something like the colon (:), as it's ratherinnocuous where implications are concerned, doesn't stand out like aketchup stain on a white shirt when someone is reading a raw .gmi file,and it will work with ASCII art, ANSI art, or anything else that maysubject the listener to cacophany. But whatever anyone comes up with between these two types of proposalsI'll be happy to implement when I author my .gmi files. I feel a sense of urgency, however, for at the very least, addressingthe matter of user accessibility now, in consideration of those whowould listen to the audible delivery of text/gemini. And for that, I feel that we will actually be best served by those whoactually author Gemini clients, as to their suggestions on how they feelbest in implementing that type of support in their products. > > > > Benefits of this proposal: > > > > - It doesn't break any existing sites; it just adds one feature. > > - It's very simple to implement: parsers scan for a single additional > > backtick > > - Authors can still provide any alt-text they wish without worrying > > about "reserved words" like the proposed tags > > Which of the above blocks should be read, and shouldn't be read? > > > - It provides *critical* semantic information: whether or not a block of > > preformatted text should be treated as readable text. > > Not enough in my opinion. > > -spc > All very valid concerns and suggestions. Just let me know soon how toalter the way in which I author my pages :) I hope that helps :) Kindest regards, -- Bradley D. ThorntonManager Network Serviceshttp://NorthTech.USTEL: +1.310.421.8268