Repository navigation
Getting the current source size value of an img #6532
Description
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.
Activity
tabatkins commentedon Mar 25, 2021
Would this be different from calling
img.getBoundingClientRect().width?eeeps commentedon Mar 25, 2021
Yes; I want something that will return
300in this example, rather than100.Then, I can compare that something to
img.getBoundingClientRect().widthto see how wrong mysizesis (at this viewport size).eeeps commentedon Mar 26, 2021
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
sizesvalue inpxisn't trivial, and it would be nice if the browser, which has already done the conversion as part ofsrcsetselection, exposed the value directly.A couple of other thoughts:
sizes, through either height-constrainedsrcsetselection, or container-relative units w/insizes, it'll be even nicer for the browser to expose this.zcorpan commentedon Mar 26, 2021
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 commentedon Mar 30, 2021
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 commentedon Mar 30, 2021
So... isn't this already exposed by
naturalWidththough? (andnaturalHeightfor height)eeeps commentedon Apr 1, 2021
@zcorpan Good point!
When your
wdescriptors are accurate and you're usingsrcsetandsizes, 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 commentedon Apr 6, 2021
@eeeps I like this
img.currentSizesidea,sizesis 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 commentedon Feb 3, 2022
If both Chrome and FF are using a package to provide something, that seems like a pretty strong vote for platform functionality
eeeps commentedon Jun 27, 2023
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.
austinh commentedon Jun 11, 2026
We came across a need for this at airbnb: #12565