💾 Archived View for gemi.dev › gemini-mailing-list › 000130.gmi captured on 2023-11-04 at 12:27:30. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Hello Geminauts
1. Are ``` lines to be block markers or mode switches?
>From the discussions on the the list, it seems like they are block markers.
The current spec calls them "toggle lines" that toggle "pre-formatted mode
being on or off" which suggests it's a mode switch.
The way I interpret the difference between the two is that blocks need to
close before end-of-file to be valid and in the other case the file can end
in any mode.
This might be splitting hairs but I want this to be clear.
2. Is it desirable to close the window of extensibility?
When reading the archives, I noticed that ``` lines used to only work if
they had no trailing characters. This was changed to be less surprising
when someone writes
```python
as if it was a markdown code block.
There is a discussion in another thread to use this space for alternative
text when entering pre-formatted mode but I have other extensions on my
mind. These extensions I will show you are not proposals I want to see.
``` Visual browsers will
``` not display these lines.
``` So as long as there are
``` an even number of them,
``` I can get away with using
``` them as comment lines.
Someone could also construct a browser that embeds media files with a
fallback to a link for other browsers:
``` @embed image/png
``` width=300 height=200
=> path/to/image.png Alt. text
I don't think we need to close this window, but I also don't see a need to
allow consecutive ``` lines.
These are real questions with added context and not opinions or rhetoric
dressed as questions.
--
Katarina
Hi Katarina, Katarina Eriksson writes: > ``` @embed image/png > ``` width=300 height=200 > => path/to/image.png Alt. text > > I don't think we need to close this window, but I also don't see a need to > allow consecutive ``` lines. I think I understand your worry, but wouldn't it be difficult to close this window? To exclude this possibility requires adding this special exclusion to the spec, and for every client to do something special to produce an error in the case of consecutive ``` lines. Even if it were in the spec, I'd be very tempted to just allow it in my client, just because ignoring this restriction would allow for a cleaner implementation and would produces no issues with correctly formatted text/gemini pages, while also allowing some incorrectly formatted pages to be displayed. (As a user, I honestly don't care whether a gopher map or text/gemini file meets the spec or not, I just want to read it.) Just my random thoughts, Tim
On Thu, May 21, 2020 at 08:31:19AM +0200, Katarina Eriksson wrote: > Hello Geminauts Hello! > 1. Are ``` lines to be block markers or mode switches? > >From the discussions on the the list, it seems like they are block markers. > The current spec calls them "toggle lines" that toggle "pre-formatted mode > being on or off" which suggests it's a mode switch. They are definitely mode switches, as stated in the spec. People tend to speak quite informally on the list - sometimes too informally for my tastes! I have noticed people referring to Gemini sites/servers as websites or webservers which always stuns me a bit... > The way I interpret the difference between the two is that blocks need to > close before end-of-file to be valid and in the other case the file can end > in any mode. There's nothing invalid about a file ending with pre-formatted mode on according to the current spec and I don't really see a need for this to change. Clients should set the value of pre-formatted mode to off when they begin pasing a new document. In general, there should be as few ways as possible for a text/gemini file to be "invalid", it should be dirt simple. To be honest, I'm kind of surprised by all the discussion around some kind of formatting/validating/linting tool for text/gemini. It doesn't bother me and people who want them can certainly write them, but to me it seems like there is so little scope for messing things up writing it by hand that tools like that feel unnecessary and cumbersome. > 2. Is it desirable to close the window of extensibility? > > When reading the archives, I noticed that ``` lines used to only work if > they had no trailing characters. This was changed to be less surprising > when someone writes > ```python > as if it was a markdown code block. That was the main motivation, but as a little side thing it also meant it became true that all line types can be unambiguously recognised by inspecting only their first 3 characters, and I liked having something that simple apply without exception. If nothing is allowed after the ``` you need to also check the line length to recognise toggles. > ``` Visual browsers will > ``` not display these lines. > ``` So as long as there are > ``` an even number of them, > ``` I can get away with using > ``` them as comment lines. My first thought: Oh, cute! Cute and neat... > ``` @embed image/png > ``` width=300 height=200 > => path/to/image.png Alt. text ...followed by "Oh, dear God, no!" :O This is a real and frightening way that clients can sneak in support for arbitrarily complicated extra functionality, and it degrades absolutely invisibly in non-supporting clients, so there is no incentive against content authors using it. I congratulate you for recognising this and thank you for bringing it to our attention! In some ways, this is the logical conclusion of all the discussion around putting stuff for clients to parse in that space. > I don't think we need to close this window, but I also don't see a need to > allow consecutive ``` lines. I don't see a need to allow consecutive ``` lines either, but I am really, really attached to the current property of text/gemini that you can handle it correctly by handling each line independently of every other line in a single top-to-bottom pass with very minimal internal state. Forbidding consecutive ``` lines would break that and require the parser to remember the type of the previous line. But I see no other way to close this window without reverting to toggle lines being strictly three-characters only, and then we lose the alt-text option. To be honest, I could live without specifying programming languages to enable syntax highlighting in text/gemini - I get that that's *nice*, but it's not really essential. But the alt-text thing kind of feels important to me, because people are right now using pre-formatted blocks to do things that ruin accessibility/searchability without it, and those things matter. I guess one could cynically ask "what makes you think people doing that right now would use alt-text to fix the problem if you gave them the means to?", and conclude that we just have to let people suffer the consequences of not using text/gemini "cleanly"... > These are real questions with added context and not opinions or rhetoric > dressed as questions. Definitely real food for thought in here. Thanks again for this post. Cheers, Solderpunk
On 5/21/20 7:52 AM, solderpunk wrote: >> ``` @embed image/png >> ``` width=300 height=200 >> => path/to/image.png Alt. text > ...followed by "Oh, dear God, no!" :O If ``` gains the alt text it will prevent this sort of abuse on accident, won't it?
Katarina writes:
> ``` @embed image/png
> ``` width=300 height=200
> => path/to/image.png Alt. text
I had not thought of using that space for something like that. This is unfortunate.
However, I am grateful to Katarina for bringing it to our attention. I think this
is important.
I also concur with solderpunk's assessment:
> To be honest, I could live without specifying
> programming languages to enable syntax highlighting in text/gemini - I
> get that that's *nice*, but it's not really essential. But the alt-text
> thing kind of feels important to me
I think accessibility is extremely important and that alt text for ascii art
is of great benefit.
I have a branch of my client, Bombadillo, built that supports alt text and
toggling off preformatted block lines in favor of their alt text (or nothing,
if there is no alt text). It works well for what it is trying to do. If alt text
became a part of the spec and was widely encouraged by the community
such that it became standard practice I think it would be really wonderful.
I also see that as a real possible thing that could happen (in a way that HTML
has struggled with).
Of note, that build of Bombadillo does NOT allow any text on the closing line
of a preformatted block. Or at the very least, it will ignore that text. I don't
know that that solves anything for the issues described by Katarina but it
might help.
Another suggestion, and I know this is rough, is to add another block type so
that there is one for readable text and one for art.
Somthing like:
```
def i_am_a_code_block():
print("How do I add alt text?")
```
~~~
: - p
~~~
Having the two types makes it fairly non-extensible. It does NOT solve the alt
text problem, which I would still very much like to see. But it does separate out
crawlable content for search engines, allow clients to let their users turn off all
ascii art,hide art for screen readers while allowing them to ask the user if they
want a preformatted text block read to them, and probably a few other uses.
Every way I try to think of adding alt text ends up being arbitrarily extendable
and hidden to users under most circumstances. This is a very big bummer. I
continue to think that alt text is essential for a free and openly expressive
platform that is accessible to all. If anyone has any ideas please post!
I suppose alt text could have its own tag, but it seems like we'd have the same
issues....
> I also concur with solderpunk's assessment: >> To be honest, I could live without specifying >> programming languages to enable syntax highlighting in text/gemini - I >> get that that's *nice*, but it's not really essential. But the alt-text >> thing kind of feels important to me well, you could make it a boolean that any amount of alt-text = art, and showing the alt-text is optional, but reccommended that way if someone tried to do such a thing, a lot of clients would see that as a kind of caption, and people would get annoyed at it and tell to stop with the nonsense alt-text... at least that's what I'd assume would happen ;) also, it would mean that someone labelling their code, would see it as art, which would be a detriment to accessibility, but otherwise not straight-out fail, which is probably good... and if allowed at all, I think they should only be allowed at the starting tag-line anyway
---