💾 Archived View for rawtext.club › ~sloum › geminilist › 007520.gmi captured on 2023-11-14 at 08:32:41. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Rethinking the link line

The Gnuserland gnuserland at mailbox.org

Wed Nov 3 16:57:52 GMT 2021

- - - - - - - - - - - - - - - - - - -

Hi DJ Chase,

this is a part of my thoughts, the problem here is media file weight; if a client is designed to show some media content in line you may stuck a tab just because the download and, as a kind author, you would not do that; by the other hand as reader when you recognize there is a media file however you still don't know the real content/weight until this is actually requested; so far you don't have choice, if you want know the content you must click on it and this may affect the rendering of the page, with <= you are sure it will download in background (and you can check it later) and your view-port is safe from unwanted content (TUI clients mostly act like this).

The point is, especially thinking to GUI clients, to decide how to serve some contents before or how to handle some content later. This might be handled directly by the GUI clients which might offer the option to download everything in background and not in line, hence the whole idea would might fall down under the recommendation category, however it would remove some ability for the authors to decide the best way to delivery specific contents.

Thanks,

TGL

On 11/3/21 10:49, DJ Chase wrote:> On Wed, 2021-11-03 at 09:14 -0400, The Gnuserland wrote:

By the way I was speaking about a predictable behavior of an external

resource, the presentation issue belongs only to all those client that

are able to display media type content in the viewport.

I feel that this would become the equivalent of HTML's `<img />` tag.

Authors would use `<=` for all link _unless they want them to be> displayed inline_, effectively making `=

` the inline-link tag.