Skip to content
This repository has been archived by the owner on Jan 9, 2020. It is now read-only.

Overriding naturalWidth / naturalHeight will break some existing tools #10

Open
andydavies opened this issue Sep 21, 2018 · 8 comments
Open

Comments

@andydavies
Copy link

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
Copy link

eeeps commented Sep 21, 2018

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
Copy link
Collaborator

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
Copy link
Author

andydavies commented Sep 22, 2018

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
Copy link

eeeps commented Nov 7, 2018

@andydavies any progress on this?

@Kaiido
Copy link

Kaiido commented Dec 5, 2018

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
Copy link
Collaborator

@yoavweiss
Copy link
Collaborator

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
Copy link
Author

@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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants