spc writes: > Or how about: lines that start with '=>' are links and are handled > differently, lines starting with a ' ' are fixed (but should be > less than N characters in length), and starting with any other character > should be reflowed until a blank line, a line staring with '=>' or > whitespace. I agree with that proposal wholeheartedly. It creates one additional simple parse case for fixed lines (that will not be truncated to N characters if they go beyond). But I do not think that additional parse to implement adds any major work or complexity to clients. I am of the opinions that link lines _should_ wrap. My reason for this is that many people may want to do url only links: => gemini://this.is.a/url/to/some/place_or_other?it-has-a-data-component-th at-exceeds-the-limit-of-characters It is reasonable to want to see the whole link before following it. So, I am in favor of: 1. Regular text and links both wrap to n (tbd) characters 2. A leading space creates a non-wrapping line that will be truncated at n (tbd) characters if it exceeds that number of chars. Clients can optionally add an ellipses. One thing to consider with wrapping or truncating links is that many terminal based clients will implement links with numbers. Given that those numbers will be based by the number of links on a page, it will be difficult for content authors to predict what the behavior of longer lines will be (where something might wrap or get cut) in order to make room for interface elements such as: => A link 13 => A link [13] A link (13) A link ( 13) => A link Any of those are reasonable and possible ways a client can represent a link on the screen. Because how clients do this will vary, things can get unpredictable. As such, what happens at what boundary should, I believe, be a part of the spec. So that people can know what to expect. They should also expect differing clients to render things mildly differently and not rely on very long lines to always appear identically. As a side note: I agree that accessibility is a solid concern. --? Sent with https://mailfence.com Secure and private email
---
Previous in thread (34 of 148): 🗣️ Sean Conner (sean (a) conman.org)
Next in thread (36 of 148): 🗣️ James Tomasino (tomasino (a) lavabit.com)