New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Intrinsicsize attribute for HTML image and video elements #129

Open
loonybear opened this Issue Jan 11, 2019 · 8 comments

Comments

Projects
None yet
4 participants
@loonybear
Copy link

loonybear commented Jan 11, 2019

Other information

We would like to introduce this attribute to allow maintaining an image's aspect ratio while one dimension is specified proportionally. Please see the link above for more details.

@emilio

This comment has been minimized.

Copy link

emilio commented Jan 12, 2019

I recall somebody talking at TPAC to the CSSWG about adding aspect-ratio-based units, but I don't recall the specifics, maybe @dbaron or @jensimmons do? How would this play with that other proposal?

Also, how does this play and interact with the sizes attribute which can already change the intrinsic size of the image? Is there any way to make it work with srcset / <source> and related responsive images stuff?

@emilio

This comment has been minimized.

Copy link

emilio commented Jan 12, 2019

Ah, I see my question was answered already in the document:

How does this work with responsive images? The 'intrinsicsize' attribute sets the image's intrinsic aspect ratio. For an image element with a srcset, if:

  • a source is chosen using the 'w' descriptor, then the result of evaluating the 'sizes' attribute sets the image's intrinsic width, and its intrinsic height will be calculated by the intrinsic aspect ratio defined by 'intrinsicsize' attribute;
  • otherwise, the 'intrinsicsize' attribute sets the intrinsic width and the intrinsic height.
@emilio

This comment has been minimized.

Copy link

emilio commented Jan 12, 2019

So looks like intrinsicsize overrides the image intrinsic size even though we know the actual source intrinsic size, is that right? Seems a bit footgunny... That means that until all browsers support the attribute it's trivial to cause behavior differences accidentally. For example let's say that I have a cat.jpeg feature that is 200x200, but I do <img intrinsicsize="100x100" src="cat.jpeg">.

That means that if the browser supports intrinsicsize the image would lay out as 100px wide all the time right? While once it loads a browser that doesn't support the attribute will lay it out as 200px and the layout would be broken. That sounds slightly unfortunate if the use-case this wants to solve is just avoiding the reflow when the image is loaded...

@annevk

This comment has been minimized.

Copy link
Collaborator

annevk commented Jan 14, 2019

This also conflicts a bit with the HTML standard which says width/height attributes are supposed to match the intrinsic dimensions (use CSS for presentation aspects). Now currently width/height attributes map directly to CSS without forwarding some kind of aspect ratio. Perhaps that's the thing that should be added.

You'd still have a rendering difference between supporting and not-supporting browsers, however.

@loonybear

This comment has been minimized.

Copy link
Author

loonybear commented Feb 8, 2019

Yes, aspect-ratio would still be a future project. But I don't see why this will stop intrinsicSize.

  1. intrinsicSize is only supported on media elements (image / video). asepect-ratio on the other hand is way more complicated than this.
  2. intrinsicSize overrides the intrinsic size of element, it will be in pixel unit, aspect-ratio provides just a ratio. However, intrinsic size should only be used if height/width is unspecified (including the case that aspect-ratio is missing), so there is no real conflicts.

To answer the other question, if you do <img intrinsicsize="100x100" src="cat.jpeg">, it will be always rendered as 100px by 100px, this prevents layout instability, it prevents contents from jumping around, which was one of the intention that intrinsicSize is being proposed.

@emilio

This comment has been minimized.

Copy link

emilio commented Feb 8, 2019

So one difference between how intrinsicsize works (as implemented in Chromium today) and how width= and height= works is that intrinsicsize works in image pixels, while width and height work in CSS pixels. This seems reasonable to me, but does not match what the explainer claims not my initial expectations. The explainer claims:

The sizes are in CSS Pixels.

But if I go to https://googlechrome.github.io/samples/intrinsic-size/ on Chromium on a HiDPI display, , the samples with intrinsicsize="250x200" are really 125x100 CSS pixels. Of course if I set width="250" height="200" instead the image is twice as big.

Is that a bug in Chrome's implementation? Or an error in the explainer? Seems pretty counter-intuitive to me.

@simevidas

This comment has been minimized.

Copy link

simevidas commented Feb 11, 2019

In @loonybear’s latest comment, the broken image appears to be <img src="cat.jpeg" style="max-width:100%;"> (in case anyone’s wondering).

@emilio I get 250x200 CSS pixels in Chrome Canary w/ flag. My screen is devicePixelRatio = 2, and when I take a screenshot of the image, it’s 500x400.

In Firefox, adding width="250" height="200" produces the same result as in Canary (at least for the first image on that demo page).

@loonybear

This comment has been minimized.

Copy link
Author

loonybear commented Feb 11, 2019

Sorry about the broken image, I updated the comment above.

Sorry I will correct the explainer, thanks for pointing that out @emilio.

In addition, we are in the process of moving the github repo to WICG, so maybe we could move some discussion there too. https://discourse.wicg.io/t/moving-intrinsicsize-attribute-to-wicg/3356

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment