search

WICG / intrinsicsize-attribute

Proposal to add an intrinsicsize attribute to media elements
Apache License 2.0
93 stars 14 forks source link

Reuse width/height attributes? #4

Open tigt opened 6 years ago

tigt commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 notifications@github.com 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 .

loonybear commented 6 years ago

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

tigt commented 6 years ago

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 notifications@github.com 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 .

loonybear commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

Yes.

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

Although, that one is a lot more complicated.

eeeps commented 6 years ago

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 commented 5 years ago

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:

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 commented 5 years ago

/cc @fantasai @emilio @zcorpan

emilio commented 5 years ago

/cc @jensimmons too.

tigt commented 5 years ago

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 commented 5 years ago

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

zcorpan commented 5 years ago

@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':

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

Which one of these do we want?

dvoytenko commented 5 years ago

@zcorpan couple of examples:

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.

fantasai commented 5 years ago

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.

dvoytenko commented 5 years ago

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

fantasai commented 5 years ago

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. :)