Skip to content

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

Closed

Description

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

image

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

Activity

  1. Loirooriol commented on Jul 3, 2017

    @Loirooriol
    Contributor

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

  2. LeaVerou commented on Jul 3, 2017

    @LeaVerou
    MemberAuthor

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

  3. Loirooriol commented on Jul 3, 2017

    @Loirooriol
    Contributor

    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.

  4. LeaVerou commented on Jul 3, 2017

    @LeaVerou
    MemberAuthor

    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.

  5. Loirooriol commented on Jul 3, 2017

    @Loirooriol
    Contributor

    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.

  6. LeaVerou commented on Jul 3, 2017

    @LeaVerou
    MemberAuthor

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

  7. FremyCompany commented on Jul 12, 2017

    @FremyCompany
    Contributor

    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.

  8. css-meeting-bot commented on Jul 19, 2017

    @css-meeting-bot
    Member

    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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions