Sean Conner sean at conman.org
Fri Feb 26 02:51:06 GMT 2021
- - - - - - - - - - - - - - - - - - -
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:
The proposal above does not require a change in the specification fortext/gemini, and could be considered a convention used.
- 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 picked a format that should be easy to find, with a limited set ofoptions that, in my opinion, seem to cover the majority of cases withpreforamtted blocks. Again with some examples, only with alt-text and NOTwith my proposal:
I think that '@poem', '@art', '@code' and '@data' would be very helpful toa client program. Adding an additional backtick for "something that isn'treadble" just seems too little.
But anyone arguing for (or against) this, please feel free to use theabove Python examples when making arguments.
This is consistent with the spirit of gemtext: characters at the
beginning of a line are the only way to describe semantics.
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