Hacker News Reader

Comment by freehunter | Hacker News Reader

Wouldn't it be nice if browsers or servers could reserve that space even if it's not loaded? Like "this is going to be a 500x200 image so let's load 500x200 pixels worth of empty space until it's fully loaded" and avoid jumping.

View on HN

I think you're being sarcastic, but if not and for anyone who isn't aware, setting the width and height on an <img> tag (or it's associated style) will do this.

This would be a great solution, if everybody used the same screen size.

The width and height of an image set in a CSS file can be in any valid CSS unit. That's pixels, or em, or a percentage, or viewport units (vw and vh for 1% of the width or height, vmin or vmax for 1% of the shortest or longest side), or real world units like mm (only works on high DPI screens). Support varies.

Eg setting an image to be "width: 100vw; height: 100vh;" means it'll be squished to fill the user's viewport. "width: 100vw; height: auto;" will fill the viewport horizontally and scale the image vertically as per it's aspect ratio. And so on. Generally that'll look bad though because browsers scale things fast rather than well.

And then there's the options for background images. "background-size: cover" is quite useful.

CSS is fun.

In many cases you want to set one size and let the other calculate itself based on the aspect ratio of an image. And this is not know prior to loading and can't be specified in any other way. So you get jumpy behavior during load on most responsive websites and slow connections. It's hard to fix in JS too.

Yes, and that's exactly what Firefox's new scrolling anchoring tries to fix.

If only there was a way to know the aspect ratio of an image at the time of website authoring...

I personally dislike the complexity of having to use the server-side calculated dimensions.

``` object-fit: cover ```

comes to mind as a client-side solution I used in the past for this problem

There are such things as dynamically sourced, or generated, images. On-the-fly-computed SVG data visualisations might be such a case.

Generally, I'd agree that authoring time is some 9X% solution, though there remain edge cases.

You'd still want those at a fixed size though?

I can't think of a good use case for auto generating arbitrarily large images, and as a user I wouldn't want to visit websites where the web designer thinks that's a good idea either.

Usually, yes, though posibly not in all cases. With SVG and CSS/JS, the size could be dynamic as the paage is being viewed, depending on user behaviour or other conditions

What thos cases are is ... a good question, and my point is more thaat this can be done than to say why or that it's a good idea.

Upshot again is that image size need not be deterministic at authoring time.

But wouldn't that require people to know what they're putting on their web site?

Doesn't help if you try to do max-width: 100% in CSS. You'll get an image with a height you set in HTML and a smaller width.

Not sure why you're downvoted. It's a real problem. It would help if it would be possible to set an aspect ratio on the img tag, so that when it's scaled via CSS or whatever, it would maintain the aspect ratio of the loaded image despite it not being loaded yet.

It's possible and well-known: https://css-tricks.com/aspect-ratio-boxes/. Also, for images, there is the simpler solution of specifying real width/height in the img tag, then use CSS with "max-width: 100%; height: auto" or anything similar.

It doesn't work in chrome. Try (test.png doesn't exist):

  <img width="100" height="100" style="width:100%;height:auto;" src=test.png>

and you'll get 16x16px placeholder image. In Firefox, it works.

It would be nice if we could have a ratio rule in CSS for all block elements, so adjusting one dimension would automatically alter the other, preserving the ratio at all screen sizes. e.g.:

    width: 2000px;
    max-width: 100%;
    ratio: 16/9;

Of course this gets tricky when width and height are both specified and they don't match the given ratio, but that just means that one needs to always override the other.

Edit to add: Or maybe it would be better to just have the ability to lock the ratio, such as:

    ratio: fixed;

Aspect Ratio is coming in CSS4. https://www.smashingmagazine.com/2019/03/aspect-ratio-unit-c...

This pleases me.

To be honest, if you know one dimension and the aspect ratio, you're more likely to know both dimensions.

Well, the thing is with `width: 9000px; max-width: 100%;` is that you know neither. And it forces people to use silly things like `padding` to maintain aspect ratio in e.g. embedded videos.

You (or others) may or may not know it is already possible in CSS as it is. To force 16:9:

  .DamnInteresting {
    position: relative;
    display: block;
  }

  .DamnInteresting::before {
    content: '';
    display: block;
    /* 16:9 shim! */ 
    padding-bottom: 56.25%;
  }

  .DamnInteresting img {
    position: absolute;
    top: 0;
    left: 0; 
    width: 100%;
    height: 100%;
  }

Ugly, but it's easy to make a mixin (or similar) if you're using a preprocessor!

(The ::before element isn't stricly necessary; the padding can go on the .DamnInteresting element directly - just make sure .DamnInteresting is wrapped in a containing element of your desired width and you can even use inline styles for the padding shim.)

(Edit: a word)

I think you're also being sarcastic :) Websites did this 15 years ago (miss the HTMLX compliant button at the bottom of the page), and now in large part do not.

I made my first website 22½ years ago. Even as a raw beginner, I knew it was considered sloth and Very Bad Form Indeed not to specify image size in my markup.

Everything that is standard recommended practice in modern web design is Very Bad From, whether or not it is sloth.

"Oh wow, 22 years ago! This guy must be... my... age... Shit."

Another solution is just to wait until computers and networks are 100 times faster than they were 10 years ago, so that a page and its pieces load instantly. Oh, wait. That speed-up already happened, and yet websites are actually slower than they were 10 years ago. I guess there is no advance in hardware that software cannot overcome.

Networks are thousands of times faster in bandwidth, but they don't have thousands of times less latency. Software is actively working to overcome the limitations of latency, such as with HTTP/2, HTTP/3, and TLS 1.3.

For a page load, why should latency matter once you get below 50 ms? The problem isn’t latency, the problem is that the software stack makes tons of round-trip requests to display some text and images. The modern web makes X11 seem like it was designed by a demoscene coder.

> For a page load, why should latency matter

> he problem is that the software stack makes tons of round-trip requests

Latency matters because of all of those round-trip requests. Each individual request incurs at least 2x the network latency value (one network latency trip out to the server, another network latency trip back). If browsers did not try to run parallel requests, then all those round trips would sum up to a substantial overall delay.

> Latency matters because of all of those round-trip requests.

Well then, since it's a physical impossibility to do away with them, we'd better start working on improving the speed of light.

> If browsers did not try to run parallel requests, then all those round trips would sum up to a substantial overall delay.

That describes zero browsers. And "it's not loading parallel enough" is very much a software stack problem and not a network problem.

We could shove full pages over the wire in 200ms if we tried harder.

X11 doesn't even do any image compression. X11 seems fast because everyone uses the DRI and/or MIT-SHM extensions to hack around the fundamental brokenness of the protocol, at the cost of network transparency. :)

`ssh -X` generally disagrees with you.

I much prefer the Web to that on a slow network connection.

Try the `-C` option as well. I think that's it. Enables network compression and it makes a HUGE difference over slow network links.

> The problem isn’t latency, the problem is that the software stack makes tons of round-trip requests to display some text and images.

From the post you replied to:

> Software is actively working to overcome the limitations of latency, such as with HTTP/2, HTTP/3, and TLS 1.3.

The whole point is to eliminate those round-trips, and just stream content to the browser at the limit of its available bandwidth.

If the browser only knew...but in many cases it doesn't, especially for a fluid width, responsive website. An image may have a near infinite number of potential dimensions depending on the user's viewport.

It could still be wrapped in a div which also has the same responsive constraints, no?

> responsive website

This theme is discussed here often, but really, this is what HTML was designed for. Load https://thebestmotherfucking.website/ in a browser and scale it at will, it will always look good. The fact that people put a ton of often useless stuff and complain it looks bad in some browser doesn't mean media queries are theonly way.

Great. Now if only all websites used one or two static images with a known size and nothing else.

Frankly, for 99% of them, I wouldn't mind.

From your mouth to God's ears.

This drove me insane with the WSJ mobile app. I stopped using it because I would continuously lose my place in the article as the various advertisement blocks loaded in.

Plenty of sites already do that with images.

The problem is mainly with ads, when 1) there may or may not be an ad available, and 2) you're allowing the ad height to be dynamic, to allow for greater possible inventory.

Then the page won't be responsive. The image width and height changes depending on your viewport size.

The client can reserve the space with a CSS media query, then. But it should be the client making that rendering decision, not the loaded asset—i.e. if you have an async-loaded iframe, the iframe shouldn't be able to resize itself on load, but rather should be sized correctly when first created (either by JS or CSS) and then the contents of the iframe should accomodate the dimensions they're loaded into. (Which can be assisted by just sending those dimensions as part of the iframe's URL—though this is bad for privacy reasons.)

> Then the page won't be responsive

That's a benefit, in my view.

>if browsers or servers could reserve that space even if it's not loaded

I believe opera 12 could do this?

Reply on news.ycombinator.com