💾 Archived View for rawtext.club › ~sloum › geminilist › 005750.gmi captured on 2024-02-05 at 11:07:26. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Bradley D. Thornton Bradley at NorthTech.US
Sun Feb 28 19:54:56 GMT 2021
- - - - - - - - - - - - - - - - - - -
On 2/28/2021 7:41 AM, Adnan Maolood wrote:
On Sun Feb 28, 2021 at 10:20 AM EST, Luke Emmet wrote:
I disagree - at present the spec lends equal weight to the two possible
interpretations of the label of the preformatted text areas
- they may be interpreted as an alternative label for screen reader
(an accessibility label since ascii art is meaningless to non-visual
users)
- they may be used for text type identification (to convey the type of
content shown, for syntax highlighting or possibly more useful semantic
purposes, for example a client may choose not to render ascii art at
all)
Currently the specification only allows for specifying the language for
computer source code, not for identifying the type of text. So this
would mean expanding the scope of the specification, not restricting it.
I am not really in favor of this.
Neither of the two current basic discussions on how to handle thisadvocate for any change in the spec - nor should they. There's no reasonto consider it for such, especially when both general concepts offer aresolution that does not suggest any changes in the spec.
My original suggestion was for a 'convention' that the authors ofclients could find consensus with that will enable the non-sightedreader to configure that client so as not to render content in betweenthe preformatted text area of a .gmi file.
That remains my concern. The rest may be worthwhile, or not, but ineither case they involve no changes to the spec.
Whether:
or:
or:
preformat = "```" [ [WSP] tag ] [ [WSP] alt-text] end-of-linetag = '@art' / '@code' / '@data' / '@poem'
None of these involve any mention (and again, nor should they) of achange in the spec.
This entire discussion evolves around what *some* clients *may*incorporate (by convention) in the form of a configurable option oftheir software so that a block of preformatted text can be opted outfrom being rendered in the Gemini browser.
In the first example a single, innocuous character can be keyed upon tosignal that *if* a client has incorporated an opt-out for displayingblocks of preformatted text for the purposes of user accessability, itwon't display that block of preformatted text to the reader.
It doesn't get in the way of reading raw gemtext, it is hardly noticableif you are, and it means nothing but part of the comment that followsthe opening markdown tag, such that it is.
The second example is simply a different character, but part of a morecomprehensive suggestion to accommodate much more than what was myinitial concern for user accessability. That too, is something that*may* or may not be adopted by authors of gemini clients.
The third example provides the same as the second suggested solution,but with a somewhat different approach that may offer more (and I dreadusing this word but I guess I must) extensibility.
Absolutely NONE of the suggestions above have anything at all to do witha channge in the spec. They do, however, require two things:
1.) Authors of gemini clients will need to decide how they are going toaddress this and either alone or with the participation of others onthis list come to a consensus as to how "they" best feel it can beintegrated into Gemini clients, while maintaining the simplicity thatSolderpunk has established is one of the paradigms of Project Gemini.
2.) People who author .gmi files will need to incorporate themethodology proscribed by the authors of Gemini clients *if* they wishto participate in making sure that the pages they author assist in theaim to deliver Gemini content to the non-sighted readers of this world,and dare I say, given the context of what Gemini is, it stands to reasonthat this number will be significant.
Providing what I've just said above. Two things *should* be considered.
1.) the method should be easy to implement in a client, in any language
2.) the method *must* be stupid simple for people like me so that I canaccommodate such user accessibility when authoring my .gmi files.
If you write gemlogs, then I think you prolly agree wholeheartedly withthat second point.
Are there really any content types besides ASCII art that clients would
need to decide whether to show or not?
Yes. And they are myriad. Consider log dumps, interminable parts listsor inventory sheets, perhaps even Microsoft EULAs (because as we allknow, if you're a living breathing organism, you're alreadynon-compliant with their licenses).
There are a thousand use cases where it might be obvious to the*Authors* of .gmi files that what they're about to publish in thoseblocks are quite simply, tl;dr.
In my opinion designating the content type is not really necessary for
the above examples. It is much simpler to treat the presence of alt-text
as an indicator that the preformatted text is not accessible.
I'm thinking that what you just suggested is a topic for anotherdiscussion. A discussion where the authors of Gemini clients incorporatea quick and easy way for the reader to change configurations and refreshthe page they're viewing, in case the reader wants to actually bepresented with what is contained within the preformatted text block.
Example: a non-sighted person wants to install a daemon, but they're aseasoned sysadmin, so they really don't want to be bothered with all ofthe syntax noise of many particular parts of a tutorial or HowTo onpulling, compiling and installing the software, most can already write aserver block in Nginx in their sleep - so that would be noise to renderthat audibly (I would think), but when they get to the page where theconfig.exs file is they may actually want to listen to all of that.
I dunno, even sighted folks skip the parts of code in tuts that theydon't need to bother with.
In any case, that's a 'feature' that the authors of some clients *may*choose to offer the people that use their software - and as far as thereader goes, that's really irrespective of whether there's Alt text orwhite space following the markdown tag (Yes, text would be nice, huh?).
So, basically, if you are wondering how many pages Stephanie's LUPA saysare currently in Gemini space, the anser at this moment is 113,310; withforty something new sites being discovered in the past day or so.
That number's not getting smaller. it's getting much bigger, much faster everyday, and at this very moment, that's a lot of .gmi files thatcontent publishers *may* try to take the opportunity to paste in theteensy little change to their pages in service to their fellow humans.
So with that in mind, I would suggest that *time is of the essence*, sothat those authoring new pages can get on board with whatever solutionis settled upon (if they choose to do so).
I hope that helps :)
Kindest regards,
-- Bradley D. ThorntonManager Network Serviceshttp://NorthTech.USTEL: +1.310.421.8268