Questions about ``` lines

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200521/e1bb
4cae/attachment.htm>

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200521/e3fb
bea0/attachment.sig>

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