Overriding naturalWidth / naturalHeight will break some existing tools

[andydavies]

trafficstars

A number of tools [1][2][3] rely on naturalHeight and naturalWidth to determine whether appropriately sized images are being served to the browser.

If naturalHeight and naturalWidth are updated to reflect the dimensions specified in intrinsicSize then the ability to get the original image dimensions will be lost and features of these tools will break.

1. Cloudinary's image analysis - https://webspeedtest.cloudinary.com/results/180920_13_25f8ec2b83dfd646663237df6e5a9e9e
2. NCC Group's Image Checker Chrome plugin - https://chrome.google.com/webstore/detail/ncc-image-checker/fphiheficgnpphmjdliclanppccfgifl?hl=en-GB
3. Google Lighthouse - https://github.com/GoogleChrome/lighthouse

[eeeps]

naturalWidth reports the “density-corrected intrinsic width” of the image, so doesn't give the “original image dimensions” when images have a density other than 1x. Images with a flexible sizes almost never have a density of 1x.

I believe Cloudinary’s tool, at least, downloads images and checks their actual pixel dimensions using tools outside of the browser. Can't speak for the others, but it seems like tools like this could use one or more additional properties on img:

• density-uncorrected intrinsic dimensions (intrinsicWidth/intrinsicHeight)
• resource density (density)
• actual pixel dimensions of the image resource (actualWidth/actualHeight)

I know I have often wanted these properties, when informally testing things. Dunno if those would fall in scope, here, or not.

[loonybear]

I was a little bit worried about having "intrinsicSize" modify naturalWidth / naturalHeight so I asked around if there was active usage of knowing the image's actual width and height. From the response I got, it didn't seem like there was any usage of naturalWidth / naturalHeight.

I am interested in learning about in which cases people would want to get the image's actual width and height from JS, though.

image width and height should be easily exposed via a new attribute, as long as there's solid evidence proving that we should support it on the web.

[andydavies]

Did a quick search though the HTTPArchive and it appears naturalWidth / naturalHeight are referenced in a few places - will try to look in a bit more depth at where it's actually used and what it's used for next week.

attribute	frequency	urls
.naturalwidth	13953	6938
.naturalheight	8814	4239

Query

SELECT
  LOWER(attr) AS attr,
  COUNT(0) AS frequency,
  COUNT(DISTINCT url) AS urls
FROM (
  SELECT
    url,
    REGEXP_EXTRACT_ALL(body,
     r'(?i)\.naturalWidth|\.naturalHeight') AS attrs
    FROM
    `httparchive.response_bodies.2018_09_01_desktop`
      WHERE
    page = url),
  UNNEST(attrs) AS attr
GROUP BY
  attr
ORDER BY
  frequency DESC

[eeeps]

@andydavies any progress on this?

[Kaiido]

I personally use naturalWidth/naturalHeight as a means to know if an image actually loaded. width/height is not reliable because of the attributes. complete just reports if a fetching is currently occurring, but doesn't say if it never loaded, loaded successfully or erred. And events may have fired before we attach them.

So maybe there are already some edge cases that would make natural* not reliable either, but IME using a simple if(!!img.naturalWidth) or if(!!vid.videoWidth) was enough to tell if the resource could be painted on a <canvas> for instance.

So I would prefer to see new IDL atttributes intrinsicWidth/intrisicHeight and let natural* & video* ones be the ones reported by the media resource (i.e also map the "density-corrected intrinsic" size to these new attributes rather than to natural* ones as it is currently).

[loonybear]

https://twitter.com/yoavweiss/status/1074614795595382784

@yoavweiss @tabatkins

[yoavweiss]

OK, so on my end of the internets, a few use-cases emerge for exposing physicalWidth & physicalHeight attributes:

• Linting tools that check if images are appropriately dimensioned (so check the discrepancy between physical dimensions and (display dimensions * screen DPR)
• Throwing an image on a canvas that is of the same exact pixel size
• Making sure that the server side sent the right response. @eeeps can clarify this one more

[andydavies]

@yoavweiss @loonybear Came across another use case at a client yesterday

They're a retailer, and as typical with many retailers have a zoom on hover behaviour for product images - the same image is being used for the zoomed and non-zoomed image.

Will dig into it more and share what I find