W3C home > Mailing lists > Public > www-style@w3.org > February 2014

Re: [css-images] Overconstrained image sizing and preserving aspect ratio: the object-sizing property

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 3 Feb 2014 10:37:15 -0800
Message-ID: <CAAWBYDDGNyaW8sBioV2+YHCD5nEVWw2TDjUB=HeWcwDRcY1EVg@mail.gmail.com>
To: "Edward O'Connor" <eoconnor@apple.com>
Cc: www-style list <www-style@w3.org>
On Fri, Jan 31, 2014 at 2:42 PM, Edward O'Connor <eoconnor@apple.com> wrote:
> However, `object-fit' doesn't affect the size of the <img> element but
> only where within the <img> the image will be painted. The result for
> many images is letterboxing that neither Alice nor Bob want. This is due
> to the design of the Default Sizing Algorithm, which favors
> author-provided explicit widths & heights over all else.

You've gotten your causality mixed up.  object-fit showed up first;
the generic sizing algorithm was something I distilled out of it and
the other sizing algorithms across our specs.

object-fit was designed to alter the size of the image *within* the
element, and not the element itself, on purpose.

> In Alice's case, what she really wants is a new property that switches
> to another sizing algorithm that does the aspect-ratio preserving effect
> of `object-fit: contain' at layout time instead of at paint time.
> Consider this <img> of Bob's:
> <img src=5x3.jpg alt="Image with an intrinsic aspect ratio of 5 by 3"
>      width=5000 height=3000>
> The image has an aspect ratio of 5:3. Alice wants to have CSS that
> favors the intrinsic aspect ratio of the image. Something like this
> would do the trick:
> img {
>   max-width: 100%;
>   max-height: 100%;
>   object-sizing: prefer-intrinsic;
> }

I agree with this use-case, but think it should be done by an explicit
aspect-ratio property, which can choose to take its value from an
object's intrinsic aspect ratio.

My earlier work on an 'aspect-ratio' property was not very good, but
I'm interested in pursuing this.

> But there's a related case that suggests we need another value for this
> new property. Consider this <img> of Bob's:
> <img src=5x3.jpg alt="Image with an intrinsic aspect ratio of 5 by 3"
>      width=2000 height=1000>
> The image has an intrinsic aspect ratio of 5:3, but Bob has specified a
> width and height that produce an aspect ratio of 2:1. Alice might want
> to have CSS that favors the intrinsic aspect ratio of the image asset,
> or she might want to have CSS that favors the aspect ratio implicitly
> specified by the author. This case is different from the Default Sizing
> Algorithm because the author-supplied width and height are not respected
> *as widths and heights* but instead only as the source of an aspect
> ratio.

Would it be acceptable to solve this case with a simple "aspect-ratio:
2 / 1;" on Alice's side?  Otherwise, another value could be added to
'aspect-ratio' that derives an aspect ratio explicitly from the
'width' and 'height' properties, as you describe.

On Mon, Feb 3, 2014 at 9:22 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
> I've run into this sort of problem before, and it is almost always solved (for me) with this:
> img {
>     max-width: 100%;
>     height: auto !important;
> }
> Thus, the height is always derived from the width, which is never more than the width of the container. The only problem is when the source code height is too tall for the page, but honestly, that has never come up in the work I do., especially since the container is usually 'height:auto' and can scroll. On vertical screens, the width is usually the first to run into the edge, and width is also often naturally less that the width of a page without needing to go wider (so 'width: auto !important' would not be a good choice).
> I could see how it could be more of a problem when trying to adapt something like a portrait to a page that is both small and height constrained (such as iBook in page-flipping mode on an iPhone).

Yeah, I think Ted brings up reasonable use-cases that have a decent
chance of tripping the failure mode of that property combination.

Received on Monday, 3 February 2014 18:38:02 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:18 UTC