I'm busy working through this excellent checklist but I am confused by this one point

<a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/us

I'm sorry <a class="user-mention notranslate" data-hovercard-type="user" data-hovercar

Hi <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="

<a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/us

Image dimensions best practices confusion about front-end-checklist HOT 8 CLOSED

thedaviddias commented on April 28, 2024

Image dimensions best practices confusion

from front-end-checklist.

Comments (8)

MrSunshyne commented on April 28, 2024 2

@webdevan I understand your point, and i have encountered such issues myself(yesterday actually), where an image that is 1200x600 is rendered on a 320px area.

The thing is though, we should not be loading larger images than needed 😅

It becomes a situation where we're avoiding one good practice(set w/h) so that a bad practice(don't set w/h) doesn't look so bad. It becomes tricky.

It's also not trivial to resize images on the fly, it'll require a backend service that is capable of automating the task.. but we've already gone out of scope here.

So we're left with two choices :

Preset width and height -> FOUC when element area is smaller than image
Don't preset width and height -> Always FOUC

(lovely debate btw)

from front-end-checklist.

MrSunshyne commented on April 28, 2024 1

@webdevan If i may explain, in other words having the width height specified in the markup avoids FOUC ( Flash Of Unstyled Content ) and is recommended practice. That way the space can be reserved even before the browser downloads the image and calculates the height.

from front-end-checklist.

thedaviddias commented on April 28, 2024

I'm sorry @webdevan, maybe I need to review my wording and explain better.

The point is that even you put widht="150" height="150", you can override with CSS and have responsive images. It's a good practice to have always dimensions on your image to help the browser to load faster the images.

Check my small example: https://codepen.io/thedaviddias/pen/wrVBqy

from front-end-checklist.

webdevan commented on April 28, 2024

Hi @thedaviddias, I think I understand now.

Do you agree with this answer on Stackoverflow? https://stackoverflow.com/a/18844438

Sure, you can have width & height attributes on the image and override it in CSS, but then (as in your example), you don't get the benefits of both (correct me if I am wrong).

Perhaps it's better to say width and height attributes are good for small images, but doesn't help for responsive (% vw/vh) sized images?

from front-end-checklist.

webdevan commented on April 28, 2024

@MrSunshyne understood.

My point is that one usually doesn't know what size window the website will be loaded in, therefore you can't predict the page width nor column width that the image will appear inside of. So you may have an image that is 1200x600 render on a screen that is 320px wide, so it doesn't help to set <img width=1200 height=600> at all. The wrong space will be reserved for the image. The browser (unfortunately) doesn't calculate and reserve the correct aspect ratio. It doesn't help to set width=100% either since the height is unknown.

My point is that setting width & height ONLY helps if you can set values that is close to the final width/height of the image once rendered on the viewer's device, and this is almost always unknown in responsive web.

If you do know the user's window size before they visit the site, or if the images are small (not 100% width), then sure, in these cases it will help to set the width/height.

from front-end-checklist.

webdevan commented on April 28, 2024

@MrSunshyne, i've been thinking about this one some more. lets look at how a page actually loads...

if you have blocking CSS in your <head> then you will get a white screen until the CSS has loaded (so you can set img width/height in CSS or on the <img> tag - it will make no difference to the rendering because the screen will be white - but CSS is better because it lets you do more: media queries, etc).

if you have non-blocking CSS then the page will render before the CSS has loaded and repaint after the CSS. then you get a horrible FOUC. it is not even worth it to add width/height attributes to images when the site is un-usable. if you have any CSS, put the w/h there.

if the image is small (eg a logo or icon) then you should specify exact px width and height (can be in CSS or on the tag, but CSS is the best place for layout stuff).

if any image is larger than 320px then you most likely need to use height: auto; max-width: 100%; (for responsive web) and there is no simple way to prevent the unknown image size issue if you have an unknown image width. you have to use more advanced aspect ratio padding tricks and stuff.

so essentially, my conclusion (unless i'm missing something): always specify img width & height where possible, and CSS is the preferred place to do it.

from front-end-checklist.

thedaviddias commented on April 28, 2024

@webdevan what do you propose as PR?

from front-end-checklist.

stale commented on April 28, 2024

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you have any question, please contact me directly at [email protected]. Thank you for your contributions to that project!

from front-end-checklist.

Image dimensions best practices confusion about front-end-checklist HOT 8 CLOSED

Comments (8)

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent