You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[css-images] object-fit: scale-down should become a flag #1578
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.
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).
@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?
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.
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.
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.
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.
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
Activity
Loirooriol commentedon Jul 3, 2017
At that point why not something like
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-downclamps as a maximum,scale-upas a minimum,noneas a minimum and maximum, andscale-anydoes not clamp).LeaVerou commentedon Jul 3, 2017
@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-anyis basically the same as no keyword, andnoneseems to be the same as the existingnonevalue, so not sure how it combines with anything else. E.g. what doesobject-fit: cover nonedo?Loirooriol commentedon Jul 3, 2017
I don't know many the use cases, it was just a quick idea which seemed more coherent than a standalone
scale-downflag. However, I think wanting to scale images up is a frequent thing, usually handled viaheight: auto; width: auto; min-height: 100%; min-width: 100%. The concrete object size would be like inheight: 100%; width: 100%; object-fit: cover scale-upin my proposal.nonewould clamp both as a minimum and maximum, so it wouldn't matter which one offill,containorcoveris used. Thenonecase could also be treated separately, withoutfill,containnorcover.fill=fill scale-anycontain=contain scale-anycover=cover scale-anynone=fill none=contain none=cover nonescale-down=contain scale-downAnd
scale-upcould default tocover scale-up, andscale-anytofill scale-any.LeaVerou commentedon Jul 3, 2017
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, andcoverworks 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 whatcoveris for! Andwidth: auto; height: autoare not needed,autois their initial value anyway.Is there any point to all these aliases?
The reason both
scale-downandcontain scale-downare 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 commentedon Jul 3, 2017
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 towidth: auto. That's why I explicitly included that, I already know it's the default value. This is not exactly whatcoverdoes, becausecovercan 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 commentedon Jul 3, 2017
Why would someone make a spanning header image with
object-fitinstead ofbackground-size? To accommodate videos?FremyCompany commentedon Jul 12, 2017
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 commentedon Jul 19, 2017
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/1578The 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