Now that the line-wrapping issue seems to be sorted, at long last, the next thing I want to quickly clear up is whether or not we really do want some kind of pre-formatted text mode (the thing we've been discussing with ``` syntax). All the header/list stuff we've talked about is definitely - and always was definitely - going to be optional and ignorable by simple clients. So I don't feel as strong a need to build consensus on that, and I'm pretty sure I'm going to spec it. But verbatim mode would likely be an obligatory thing to implement, if only because if it's in the spec at all, some authors will produce content with would-be Gemini links in it, under the expectation that clients won't try to parse them as links because they're within a verbatim text block. Some of these lines may not actually use valid link syntax, for the purposes of teaching newbies how *not* to format their links, so clients which ignore the ``` lines may find themselves in trouble (although, ideally, all clients should be robust against malformed link lines - Sean, is that in the torture test?). I don't think there's any question that such a facility would have legitimate and useful applications, the quesiton is whether they provide enough value to be worth the increased implementation effort - which, for the record, is quite low. The only reason I think this is worth questioning is that the *original* reason having such a feature was proposed on this list was as a work-around to our old style of text reflow breaking lists. The idea was that bulleted lists could be enclosed in ``` lines to prevent the lines all getting joined together. This was never a great solution in the first place (as was discussed on the list, it just meant that content would display weirdly if any individual list item was longer than a single line on a given client's display), and now it is totally unecessary as our new line-wrapping solution doesn't break lists, or poems, or source code. As far as I see it, the main arguments in favour of a preformatted block concept now are: 1. The ability to include text/gemini syntax without it actually being rendered by the client, so Gemini can be discussed/taught over Gemini. 2. The ability to insist that some content (e.g. source code, ASCII art), be rendered in a monospace font, even by graphical clients which might display text in a variable width font by default. Point 2. could in principle be nullified by mandating the use of monospace fonts for all clients, but I think this is a pretty bad idea and conflicts with the idea that clients should be *able* to make reading text/gemini a typographically pleasant experience. I think the case is strong enough to spec these, but I recall at least one person already suggested we shouldn't, so I'm willing to hear counter arguments, if anybody wants to provide them. Cheers, Solderpunk
On Wed, Feb 5, 2020 at 4:22 AM solderpunk <solderpunk at sdf.org> wrote: > As far as I see it, the main arguments in favour of a preformatted block > concept now are: > > 1. The ability to include text/gemini syntax without it actually being > rendered by the client, so Gemini can be discussed/taught over > Gemini. > 2. The ability to insist that some content (e.g. source code, ASCII > art), be rendered in a monospace font, even by graphical clients > which might display text in a variable width font by default. I would like to tack on another argument in favor of the ``` blocks that I think is still valid after the recent changes. 3. The ability for GUI clients to display preformatted text blocks in a container with horizontal scrolling. To see exactly what I mean by this, try opening this page on a mobile browser [0]. The page banner is ASCII art which can be scrolled left and right using your thumb. The rest of the text on the page is wrapped to fit the screen. This is the type of interface that I envision gemini GUI clients evolving to support. For gemini clients that choose to implement it, it would give them an escape hatch from this section of the spec: > Authors who insist on hard-wrapping their content MUST be aware that > the content will display neatly on clients whose display device is as > wide as the hard-wrapped length or wider, but will appear with > irregular line widths on narrower clients. [0] https://github.com/michael-lazar/hn-gopher/blob/master/README.md - mozz
It was thus said that the Great solderpunk once stated: > (although, ideally, all clients should be > robust against malformed link lines - Sean, is that in the torture > test?). No, but what would a malformed link look like? I mean, I can get all nasty with invalid characters in the scheme, path, host, etc., but how tortuous do we really want to get? -spc
On Wed, Feb 05, 2020 at 06:40:06PM -0500, Sean Conner wrote: > No, but what would a malformed link look like? I mean, I can get all > nasty with invalid characters in the scheme, path, host, etc., but how > tortuous do we really want to get? Well, my first thought was quite a bit simpler than that - I wonder how many clients would choke on the below? => There's no URL here, chump! or => I forgot which way around link and text go gemini://whoops.doh Cheers, Solderpunk
It was thus said that the Great solderpunk once stated: > On Wed, Feb 05, 2020 at 06:40:06PM -0500, Sean Conner wrote: > > > No, but what would a malformed link look like? I mean, I can get all > > nasty with invalid characters in the scheme, path, host, etc., but how > > tortuous do we really want to get? > > Well, my first thought was quite a bit simpler than that - I wonder how > many clients would choke on the below? > > => There's no URL here, chump! > > or > > => I forgot which way around link and text go gemini://whoops.doh I would expect the following requests: gemini://gemini.conman.org/test/torture/There%27s gemini://gemini.conman.org/test/torture/I but I do see your point. -spc
It was thus said that the Great solderpunk once stated: > On Wed, Feb 05, 2020 at 06:40:06PM -0500, Sean Conner wrote: > > > No, but what would a malformed link look like? I mean, I can get all > > nasty with invalid characters in the scheme, path, host, etc., but how > > tortuous do we really want to get? > > Well, my first thought was quite a bit simpler than that - I wonder how > many clients would choke on the below? > > => There's no URL here, chump! > > or > > => I forgot which way around link and text go gemini://whoops.doh Okay, I added some more torture tests, and even found a bug in my server with test 0031 (in preparation of dealing with bad requests). -spc
---
Previous Thread: [SPEC-CHANGE] Full text reflow is out, long line wrapping is in