Rethinking the link line

[The Gnuserland]

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.
>
>