[css-images] object-fit: scale-down should become a flag

[LeaVerou]

Spec: https://drafts.csswg.org/css-images-3/#the-object-fit

Currently, scale-down is defined as a separate value:

scale-down
Size the content as if none or contain were specified, whichever would result in a smaller concrete object size.

The choice of making this mean "contain or none" instead of "cover or none" is rather arbitrary and non-obvious. Furthermore, the "cover or none" use case is more common, since there is a ton of images on the web that are cropped to a square or other limited rectangle and typically you want them to cover the entire area UNLESS that would mean scaling them down, which is an absolute no-no.

For example, take a look at this:

This is currently using object-fit: cover, which causes the last image to be horribly enlarged, since it's just a favicon. Using object-fit: scale-down would fix the last image, but break the others. There is currently no value for object-fit that fixes this.

Therefore, I would suggest changing the grammar from fill | contain | cover | none | scale-down to fill | none | [contain | cover] || scale-down and scale-down on its own would be defined as equivalent to contain scale-down for backwards compat.

CC @tabatkins @fantasai

[Loirooriol]

At that point why not something like

[fill | contain | cover] || [scale-down | scale-up | scale-any | none]

where the first part specifies the desired filling style, and the second part specifies if the default size should be used as a clamp (scale-down clamps as a maximum, scale-up as a minimum, none as a minimum and maximum, and scale-any does not clamp).

[LeaVerou]

@Loirooriol what are the use cases for this extra complexity? We don't typically add features without use cases for the sake of completeness alone. You almost never want to scale images up because upsampling deteriorates quality. In the few cases where upsampling is ok, there is no point in restricting it with a boundary. scale-any is basically the same as no keyword, and none seems to be the same as the existing none value, so not sure how it combines with anything else. E.g. what does object-fit: cover none do?

[Loirooriol]

I don't know many the use cases, it was just a quick idea which seemed more coherent than a standalone scale-down flag. However, I think wanting to scale images up is a frequent thing, usually handled via height: auto; width: auto; min-height: 100%; min-width: 100%. The concrete object size would be like in height: 100%; width: 100%; object-fit: cover scale-up in my proposal.

none would clamp both as a minimum and maximum, so it wouldn't matter which one of fill, contain or cover is used. The none case could also be treated separately, without fill, contain nor cover.

fill = fill scale-any
contain = contain scale-any
cover = cover scale-any
none = fill none = contain none = cover none
scale-down = contain scale-down

And scale-up could default to cover scale-up, and scale-any to fill scale-any.

[LeaVerou]

However, I think wanting to scale images up is a frequent thing, usually handled via height: auto; width: auto; min-height: 100%; min-width: 100%.

I have never seen anything like this in my 12 years of web dev. Most designers wouldn't be caught dead upscaling images. If it’s a "frequent thing", surely you can remember at least a couple of use cases? All I can think of is spanning header images, but that's typically done via background, as it should, and cover works fine in that case.

Btw with min-width: 100%; min-height: 100% you’re just expressing that the image should be at least as big as the container, not at least as big as its intrinsic size. This is exactly what cover is for! And width: auto; height: auto are not needed, auto is their initial value anyway.

none would clamp both as a minimum and maximum, so it wouldn't matter which one of fill, contain or cover is used. The none case could also be treated separately, without fill, contain nor cover.
fill = fill scale-any
contain = contain scale-any
cover = cover scale-any
none = fill none = contain none = cover none
scale-down = contain scale-down
And scale-up could default to cover scale-up, and scale-any to fill scale-any.

Is there any point to all these aliases?
The reason both scale-down and contain scale-down are allowed in my proposal is backwards compat with the current values, not some philosophical notion of completeness.

Bottom line is, we don’t typically add syntax without use cases. So far you have not demonstrated any use cases. If you want to continue discussing this, you need to demonstrate actual, widespread use cases.

[Loirooriol]

Yes, it's basically used in header images. Here you have an example: http://mengem.ara.cat/salut_i_nutricio/aliments-saludables-integrals-greix-sucre_0_1541246081.html. I think there is some wordpress theme with something similar. And I'm sure I saw people asking about this at stackoverflow.

I disagree that header images should necessary be background images, if they are part of content and not only decorative they should be HTML images. Of course min-width: 100% refers to the containing block, but the intrinsic size is used as a minimum thanks to width: auto. That's why I explicitly included that, I already know it's the default value. This is not exactly what cover does, because cover can both upscale or downscale. The point in the aliases would be backwards compatibility between the longhands and the shorthands.

Sorry it seems I misunderstood the reasoning behind your proposal, and I have been spamming this thread longer than planned. So I better stop.

[LeaVerou]

Why would someone make a spanning header image with object-fit instead of background-size? To accommodate videos?

[FremyCompany]

There might be other reasons, but one is it could be for a11y purposes. If your header contains text or logo, you might want to use <img alt> instead of a convoluted aria workaround.

[css-meeting-bot]

The CSS Working Group just discussed object-fit: scale-down should become a flag, and agreed to the following resolutions:

• RESOLVED: Accept the change in https://github.com/w3c/csswg-drafts/issues/1578

The full IRC log of that discussion

<dael> Topic: object-fit: scale-down should become a flag
<dael> github: https://github.com//issues/1578
<dael> fantasai: Can we do update WD of display?
<dael> astearns: I thought we resolved on that.
<dael> fantasai: Okay.
<dael> leaverou: Currently scale down is defined as contain or none. If contain wouldr esult in enlargement it's treated as same as none. This was defined at time cover was rare. Today we have a lot of images that are treated to cover the entire background. I'm sure you recognize this, we see it over the web. THe scale down behavior would be useful, but it's deinfed as contain or none
<dael> leaverou: It's unpredictable that it's defined tahat way based on the name. I suggested scale-down becomes a flag used with cover or contain. When it's on it's own it can be defined as contain.
<dael> leaverou: I discussed with fantasai and she agreed. We wanted to run by the group.
<dael> TabAtkins: Sounds reasonable to me
<dael> astearns: Other opinions?
<dael> astearns: Doesn't seem like there's a backwards compat because we can define scale-down by itesel.
<dael> ??: Is there a github?
<leaverou> https://github.com//issues/1578
<dael> astearns: Yes. 1578
<dael> s/??/iank
<iank_> looks ok, thanks.
<dael> [pause for github reading]
<rachelandrew> I think this would be useful behaviour
<dael> astearns: I'm not hearing objections. Lots of positives
<dael> RESOLVED: Accept the change in https://github.com//issues/1578