Hi Philip, it is so cool that you guys were able to redefine in such technical fashion what I felt from a simple user stand point! Eventually it looks like it wasn't just bikeshedding... ;-) I hope this topic may go forward! Thanks, TGL On 11/3/21 20:01, Philip Linde wrote: > Hi TGL! > > On Tue, 2 Nov 2021 09:46:17 -0400 > The Gnuserland <gnuserland@mailbox.org> wrote: > >> This flavor forbids any suitable content to be displayed in line even if >> the client is capable and should not used to provide link to GMI files. > Note that according to the current specification, clients "MUST NOT > automatically make any network connections as part of displaying links > whose scheme corresponds to a network protocol". The notion that a > client should automatically make additional requests to display content > in-line is already antithetical to Gemini and is forbidden by the spec. > > I suppose that such a feature could be useful for clients that may > display resources in-line only upon activating a link, but a common way > to address the problem of downloading such resources in web browsers is > to allow saving of the currently open resource or a linked resource via > a context menu. I think that something to that effect could work for a > Gemini client. > > You note elsewhere that this wouldn't be a major breaking change. I > completely disagree. No existing clients can currently parse "<=" > links. For that reason, new pages adopting the proposed feature would > break every existing client. Moreover, any content that for any reason > currently has a line starting with "<=" with no intention of using > this feature would incorrectly be interpreted as a link by a client > implementing this feature, although this seems less likely. > > A good work-around is mentioned elsewhere. Give the content some > content-type that couldn't reasonably be rendered by any client for > its ambiguity, like application/octet-stream. >
---
Previous in thread (9 of 10): 🗣️ Philip Linde (linde.philip (a) gmail.com)