User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.86 Safari/537.36 Steps to reproduce: 1. Visit http://codepen.io/davidmh/pen/PZooJL/ 2. Check the reported numbers for natural width and height 3. (optional) Resize the window and see the natural sizes change Actual results: The natural width and height do not match the real image sizes. Expected results: The natural width and height should report the real image dimensions.

if you use this in your css, it's supposed to happen. ---------------------- img { display: block; width: 100%; } ---------------------- remove width:100%; from the css to see what happens. thanks

(In reply to [:Towkir] Ahmed from comment #1) > if you use this in your css, it's supposed to happen. > ---------------------- > img { > display: block; > width: 100%; > } > ---------------------- > remove width:100%; from the css to see what happens. > thanks Hello Ahmed, I'm not talking about the CSS width of the image. I am aware of the effect of assigning the 100% causes. I'm talking about the properties image.naturalWidth and image.naturalHeight on the image, which are supposed to be the size of the actual file. Please refer to the JavaScript portion of the example to see what I'm talking about. I forked the original example using the same CSS rule, but a regular image tag. http://codepen.io/anon/pen/JGjmJo As you can see, the natural width and height on that example do match the real size of the image, regardless of the CSS width applied on the image tag.

can you decide what this report is about actually arni ?

If we have <img srcset="image_url Xw, " style="width:100%"> in a frame then: X/real_width_of_frame == real_image_height/img.naturalHeigh == real_image_width/img.naturalWidth Instead of 1 == real_image_height/img.naturalHeigh == real_image_width/img.naturalWidth Also, inspector tooltip also reports wrong size of image (apparently it uses ".naturalHeight/Width")

naturalWidth is very much not part of the CSSOM; it's just DOM. What's intersting to me is that Chrome has identical behavior here. On the code level, what's going on here is that when HTMLImageElement::NaturalWidth calls mResponsiveSelector->GetSelectedImageDensity() it's getting back numbers like 1.0270645385149202. And these numbers depend on the width. They come from mozilla::dom::ResponsiveImageCandidate::Density and the mType there is eCandidateType_ComputedFromWidth. So it makes sense that as the width changes the return value as far as that goes. Per spec, https://html.spec.whatwg.org/multipage/embedded-content.html#density-corrected-intrinsic-width-and-height says: The image's density-corrected intrinsic width and height are the intrinsic width and height after taking into account the current pixel density. The "current pixel density" is a property of the image request and it gets set by <https://html.spec.whatwg.org/multipage/embedded-content.html#select-an-image-source>. This algorithm is run whenever a resize happens, and returns the associated pixel density from the selected srcset entry. The srcset entries are determined by https://html.spec.whatwg.org/multipage/embedded-content.html#update-the-source-set which ends up calling https://html.spec.whatwg.org/multipage/embedded-content.html#normalise-the-source-densities which for the width descriptor case here does "the width descriptor divided by the source size". The source size is determined by the "sizes" attribute (see <https://html.spec.whatwg.org/multipage/embedded-content.html#the-img-element:source-size-2-4>), and if that's not present falls back to the width attribute, and if that's not present falls back to "100vw" (see <https://html.spec.whatwg.org/multipage/embedded-content.html#parse-a-sizes-attribute>). All of which is to say that if you specify width descriptors but not a "sizes" attribute then your naturalWidth will in fact depend on the viewport width, because you end up dividing by the length "100vw" resolves to when determining pixel densities. As far as I can tell, we're implementing the spec correctly here.

(In reply to Boris Zbarsky [:bz] from comment #5) Sorry for not asking you first. But doesn't that mean that the spec is "not perfect"? I'm going to file a bug about Devtools (tooltip shows a small pic and says 6557 x 5737). Should I?

> But doesn't that mean that the spec is "not perfect"? I don't know, honestly. This is not a part of the spec I know very well. It _looks_ to me like the idea is that you're supposed to use width descriptors with the "sizes" attribute and that if you don't have a "sizes" attribute the spec just picks _something_ to be able to produce a number. But I don't know for sure. Maybe Josh does... I don't know enough about the context of the devtools thing to answer your question about it.

Thank you, Boris and Arni. I was hesitant about creating this ticket because of that description about the naturalWidth on the spec. I'll try to get some clarification from the WHATWG, and post any relevant response here just for reference.

If you like to keep track of this: https://github.com/whatwg/html/issues/381#issuecomment-163367578

I don't know much about the intended uses of parts of the responsive images spec, unfortunately, so I don't have anything to add here. Looks like there hasn't been a response to the question in the github issue, either.