Getting the current source size value of an img

[eeeps]

Sizes is hard and debugging it is hard.

Being able to automate debugging without implementing a sizes parser would be nice. I'd like to be able to compare img.clientWidth with something (img.currentSizes?) that gave the current source size value in px. So, when:

window.innerWidth = 1000

this img

<img sizes="(min-width: 600px) 80vw, 100vw">

would have an currentSizes (or whatever) of 800.

[tabatkins]

Would this be different from calling img.getBoundingClientRect().width?

[eeeps]

Yes; I want something that will return 300 in this example, rather than 100.

Then, I can compare that something to img.getBoundingClientRect().width to see how wrong my sizes is (at this viewport size).

[eeeps]

Spent a morning figuring out what I can do on my own: https://codepen.io/eeeps/pen/MWJyJKG?editors=1111. Not sure what I have is correct...

(This would be a lot cleaner/easier with something like w3c/css-houdini-drafts#798)

In any case, turning a source-size-value into an integer representing the resolved sizes value in px isn't trivial, and it would be nice if the browser, which has already done the conversion as part of srcset selection, exposed the value directly.

A couple of other thoughts:

• If we get more-complicated sizes, through either height-constrained srcset selection, or container-relative units w/in sizes, it'll be even nicer for the browser to expose this.
• I'm working on a Responsive Images Client Hints polyfill; this would be very useful for that, too.

[zcorpan]

This makes sense to me, and it seems easy for browsers to expose this information, and as demonstrated, relatively hard for web developers to get right. If you want to get it right including error handling or CSS syntax edge cases (e.g. /* , */), it's really hard to get right (or you'd need to pull in a CSS parsing library).

[tabatkins]

Yeah, the use-case seems a little narrow, but reasonable, and the cost to expose it (pretty low) vs the cost to figure it out yourself (pretty high) seems to lean towards it being worthwhile to add.

[zcorpan]

So... isn't this already exposed by naturalWidth though? (and naturalHeight for height)

[eeeps]

@zcorpan Good point!

When your w descriptors are accurate and you're using srcset and sizes, yes.

Sometimes, though, no. Here are some tests of some edge cases I could think of: https://codepen.io/eeeps/pen/bGgqExq

For linting purposes, I care a bit about the "incorrect w descriptor" case.

When it comes to client hints (linting them, or polyfilling them), I care a lot about the "no srcset" case.

I think all of the ❌s would be ✅s if we did #3981, though?

[nhoizey]

@eeeps I like this img.currentSizes idea, sizes is indeed complex to debug.

I wonder if the code from the parse-sizes package (used in this "Sizes" extension for Firefox and Chrome) could help build something, while it's not native yet.

[tigt]

If both Chrome and FF are using a package to provide something, that seems like a pretty strong vote for platform functionality

[eeeps]

I think sizes=auto (and its emerging complexities) makes this even more important. Developers are going to assume that sizes=auto is doing the right thing when if they're not careful, it won't. cc) @zcorpan

I'm imagining a Lighthouse test or whatever that can check if sizes.currentSizes === img.clientWidth onload for imgs with sizes=auto. If not, there's been some hard-to-see problem.