Reuse width/height attributes?

[tigt]

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

[loonybear]

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

[tigt]

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 ***@***.***> 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 <#4 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHstSnd6Tw60AHOaqltRDM0HnE-jGCf3ks5uIMnbgaJpZM4VOMq2> .

[loonybear]

No. I am trying to understand how this proposal would work to solve the issue raised in the explainer.

[tigt]

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 ***@***.***> 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 <#4 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHstSq9YGQUcmUloZr26SPz3NSJB7aGSks5uIPJWgaJpZM4VOMq2> .

[loonybear]

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.

[tigt]

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.

[loonybear]

Yes.

I am personally leaning towards this proposal. I think it is so great.

Although, that one is a lot more complicated.

[eeeps]

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.

[dvoytenko]

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.

[yoavweiss]

/cc @fantasai @emilio @zcorpan

[emilio]

/cc @jensimmons too.

[tigt]

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.

[dvoytenko]

@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.

[zcorpan]

@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?

[dvoytenko]

@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.