intrinsicsize-attribute
intrinsicsize-attribute copied to clipboard
WICG
Reuse width/height attributes?
Apologies if this was in the Alternatives Considered section — I didn't quite see something that seemed the same.
What if width/height were used as normal, and a boolean attribute would indicate they result in the aspect ratio to maintain?
<img width="450" height="625"
scaleratio> <!-- aspect ratio defined as 18:25 -->
Hi, I am just trying to understand how to set the height and boolean attribute as suggested if I set width to be 100% of its containing block's width?
Thanks
Are you trying to accomplish that in a web page right now? This issue is proposing a not-yet-real attribute, so it doesn't work anywhere.
On Thu, Jul 19, 2018, 2:03 PM Luna Lu [email protected] wrote:
Hi, I am just trying to understand how to set the height and boolean attribute as suggested if I set width to be 100% of its containing block's width?
Thanks
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ojanvafai/intrinsicsize-attribute/issues/4#issuecomment-406364429, or mute the thread https://github.com/notifications/unsubscribe-auth/AHstSnd6Tw60AHOaqltRDM0HnE-jGCf3ks5uIMnbgaJpZM4VOMq2 .
No. I am trying to understand how this proposal would work to solve the issue raised in the explainer.
Of course, I'm sorry for my rudeness.
If width=300 and height=500, and this attribute is set, then if CSS sizes the element to be 100% of the parent container, then the element's height will become 1⅔× the container's width.
Does that work?
On Thu, Jul 19, 2018, 4:55 PM Luna Lu [email protected] wrote:
No. I am trying to understand how this proposal would work to solve the issue raised in the explainer.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ojanvafai/intrinsicsize-attribute/issues/4#issuecomment-406411533, or mute the thread https://github.com/notifications/unsubscribe-auth/AHstSq9YGQUcmUloZr26SPz3NSJB7aGSks5uIPJWgaJpZM4VOMq2 .
I see. Yes that seems like it would work. What about responsive images. How does that work for responsive case? Sorry I am pretty new to web development and I have lots of questions.
That's a good question. The srcset syntax allows an h token to future-proof possible height-based source selection, but the WICG folks behind that spec would probably know more.
@eeeps, do you know how that turns out?
As for <picture> with multiple <source>s, I guess we could allow this attribute, width, and height on each <source> element, but maybe that's not as elegant as allowing the h token in srcset to influence image height, like how the w token influences image width unless overriden with CSS.
Yes.
I am personally leaning towards this proposal. I think it is so great.
Although, that one is a lot more complicated.
Re: h
It was initially proposed (by @yoavweiss) as a way to give images intrinsic dimensions before they were loaded – solving exactly the problem that @ojanvafai is trying to solve, here.
I asked if h descriptors might also pave the way for height-constrained-selection – which is a different problem. In order to solve it, consensus was that we’d need both an h descriptor in srcset and significant changes to how sizes works.
These two use cases were deemed significant, but not significant enough to block the first specs or implementations. h did get some special treatment, though – whereas other unknown descriptors will cause a resource to be dropped from consideration, h was special cased for future compatibility, and is simply ignored.
Despite apparent consensus, in the four years since all of those conversations, nobody ever implemented or spec’d h.
Implementing h for just intrinsic height (without trying to solve the layout-height-constrained-image use case at the same time) seems (to someone who’s never worked in Chromium) more-or-less just-as-complicated as implementing new attributes (intrinsicheight+intrinsicwidth), and perhaps less fraught than implementing a modifier for existing attributes. As I argue in the other issue, h’s relationship to responsive images also seems cleaner.
We've run a fairly large sampling of <img> tags with both valid width and height attributes from Google Search index and we looked at the aspect ratio defined by the width and height attributes vs the actual intrinsic width/height from a downloaded images. In other words, we computed definedAspectRation / intrinsicAspectRatio and we found:
- Discrepancy was over 1.01 in 15% of
<img>elements, - Discrepancy was over 1.1 in 11% of
<img>elements, - Discrepancy was over 1.2 in 8% of
<img>elements.
As you can see, the discrepancies are significant in noticeable percentages of cases. And this doesn't take into account cases where one of width or height attributes was missing, or had an invalid value such as "auto" or "NaN".
I believe if we were to try to use the current width and height attributes, we'd need to change the default value of the object-fit CSS right away as described in #14.
The (very) minor discrepancies might be from how width and height only take integers, and when resizing one, the other might calculate to something fractional.
The really big discrepancies are probably spacer.gif, if I had to guess.
@tigt The data I provided already explicitly excludes float/integer rounding issues. I tried to remove cases that look like spacer.gif and the data looks a bit better:
- Discrepancy was over 1.01 in 13% of
elements,
- Discrepancy was over 1.1 in 9% of
elements,
- Discrepancy was over 1.2 in 6% of
elements.
@dvoytenko can you provide a few examples of pages in the "Discrepancy was over 1.2" category? It's difficult to assess the visual impact from a number.
So, wrt changing the default of 'object-fit':
- If the page uses width/height that doesn't match with the image's intrinsic dimensions, and 'width' or 'height' are not set to auto with CSS, then the image will be stretched.
Is it common to have width/height set, and then set one of them to auto with CSS? (A common case is probably max-width: 100%; height: auto, but don't know how common it is on the web.)
- If the intrinsic dimensions from width/height are used before the image is loaded, and the image's intrinsic dimensions are used after the image is loaded, the end result is the same as today. The layout during load would not be stable, but it would jump around less compared to today.
- If the intrinsic dimensions from width/height are used even after the image is loaded, then the end result will have noticeably stretched images in some % of cases. A way around it is to change 'object-fit' default.
Which one of these do we want?
@zcorpan couple of examples:
- https://www.anesthesiaplanet.com/images/banners/IMG_0036.JPG in https://www.anesthesiaplanet.com/blog/categories/listings/pre-professional (defined as 468x60, but actually 326x245)
- https://i206.photobucket.com/albums/bb239/jadesheart_photo/glitter/glitter-smile.jpg in https://www.ebay.it/itm/EXTENSION-CHERATINA-REMY-5A-CAP-VERI-100-CIOCCHE-52CM-100G-SHATUSH-1B-ROSSE-/232333969369 (defined as 310x90, but actually is 302x294)
- https://www.dekorup.com/wp-content/uploads/2017/11/modern-hos-tasarimli-kalorifer-petek-modelleri.jpg in https://www.dekorup.com/ankastre-ocak-temizligi/ (defined as 140x90, but actually is 1030x726)
Which one of these do we want?
I think what we want functionally is described fairly well in the explainer and for object-fit the proposal is #14.
Is it common to have width/height set, and then set one of them to auto with CSS? (A common case is probably max-width: 100%; height: auto, but don't know how common it is on the web.)
From what I understand, it's fairly common, and becoming more popular as people update to responsive design techniques and create fluid layouts with Grid and Flexbox.
Which one of these do we want?
I don't think we can change the object-fit default: that default behavior has been around since the 1990s, and for certain classes of images it's intentional that the image squish.
It would be simpler to map to the proposed CSS aspect-ratio property if we made the explicit aspect ratio win over the intrinsic one, but if it's not Web-compatible due to excessive author error, then we can make the intrinsic one win. :) (Maybe aspect-ratio gains a keyword to say whether it prescribes the ratio for replaced elements or only supplies a fallback, so that it can represent this behavior.)
@dvoytenko Wrt the data in https://github.com/WICG/intrinsicsize-attribute/issues/4#issuecomment-492358676 you will want to consider only the images with an auto height or width (in CSS): any others will not change under the proposal because their size is set explicitly--and that explicit size will continue to be honored. If that's hard to compute, just taking a random manual sample to evaluate the impact would be sufficient. Fwiw of the three examples you gave, afaict two would degrade if the explicit aspect ratio prevailed (their heights are set to auto in CSS), but the third is already skewed so it would see no change.
@fantasai
and that explicit size will continue to be honored
Could you clarify this?
Wouldn't both auto and non-auto images be resized late on image load? The deferred layout is what this proposal tries to tackle, so I think both cases are subject to it.
It would be simpler to map to the proposed CSS aspect-ratio property if we made the explicit aspect ratio win over the intrinsic one,
I agree - I think CSS aspect-ratio could be really helpful here, but I think that work on CSS side is mostly stuck? But maybe we should open a new issue to discuss CSS aspect-ratio vs intrinsic-size?
I think another possible benefit is that CDNs could rewrite documents to insert intrinsicsize automatically which should mostly be compatible with the current state, but work faster and avoid deferred layout. Something like this would be harder for CDNs to do via CSS.
Wouldn't both auto and non-auto images be resized late on image load? The deferred layout is what this proposal tries to tackle, so I think both cases are subject to it.
No. If an image has a fixed CSS width/height value, then that size must be honored. (And unless overridden by CSS, the HTML width/height attributes map to CSS width/height values.) The intrinsic size of the image is ignored in these cases, because the author gave an explicit one and this overrides. See https://www.w3.org/TR/CSS2/visudet.html#inline-replaced-width The intrinsic sizes (and aspect ratio) of an image only come into play for calculating auto sizes.
I agree - I think CSS aspect-ratio could be really helpful here, but I think that work on CSS side is mostly stuck? But maybe we should open a new issue to discuss CSS aspect-ratio vs intrinsic-size?
CSS aspect-ratio, to satisfy its use cases, needs to override the intrinsic aspect ratio. We can add the ability to let the intrinsic aspect ratio override instead if it's needed here, however.
(It's stuck mainly waiting on me to address @dholbert's comments and clean up the rest of spec. But there's an Editor’s Draft here https://drafts.csswg.org/css-sizing-4/#aspect-ratio and I really should target the June F2F for that. :)