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

Re: [css3-images] Probably editorial: 'object-fit' values 'cover' and 'contain' contain redundant definition

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 29 Feb 2012 08:20:59 -0800
Message-ID: <CAAWBYDA8sd2keNCv1Sym2H_24K8FQMCbih5ynCs-+Z4=ED18qA@mail.gmail.com>
To: fantasai <fantasai.lists@inkedblade.net>
Cc: www-style@w3.org
On Feb 29, 2012 3:11 AM, "fantasai" <fantasai.lists@inkedblade.net> wrote:
> I'm having trouble loading it all in my brain in order to explain it, but
> IIRC it's sufficiently explained here:
>  http://lists.w3.org/Archives/Public/www-style/2011May/0638.html

The basic issue being addressed here is that in some cases you end up with
unsatisfiable sets of constraints.  For one clear example, imagine an image
with a 1:1 aspect ratio, a specified width of 100px, and a min-height of

As a general principle we treat min/max constraints as gospel, so we can
assume that we must honor it.  We're then stuck with either violating the
aspect ratio and making it 100x200, or violating the specified width and
making it 200x200.

CSS 2.1 requires the former behavior, but its desirable to allow elements
to opt into the latter behavior. This is what the current text for
object-fit: contain or cover does.

I disagree with this behavior. I think it is confusing for this behavior
switch to be hidden in object-fit. In the future when we add the
aspect-ratio property or something similar, regular elements will want this
sort of behavior switch as well, and it would be completely inappropriate
to use object-fit for them as well.

So, I'd like to drop this aspect of the object-fit behavior, and address
the use case in some future draft, such as whichever one ends up with the
aspect-ratio property.

On Feb 29, 2012 3:11 AM, "fantasai" <fantasai.lists@inkedblade.net> wrote:

> On 02/22/2012 08:00 AM, Tab Atkins Jr. wrote:
>> On Wed, Feb 22, 2012 at 3:00 AM, Leif Arne Storset<lstorset@opera.com>
>>  wrote:
>>> Ah, didn't realize that was a rejection (rather than a postponement).
>>> I disagree (i. e. agree that it is out of scope). You're right that they
>>> are
>>> not redundant with each other, but the first definition is redundant with
>>> the now more robust CSS 2.1 section 10.4.
>>> I can live with it, though, since it's not incorrect, and I've already
>>> implemented and understand what it's talking about. :) I do think it is
>>> very
>>> confusing for first-time readers.
>>> (Just now I realized that the introduction also mentions this behavior:
>>> "[The property] also enables scaling a replaced element up to a specified
>>> maximum size or down to a specified minimum size while preserving its
>>> aspect
>>> ratio.". That should also have been deleted in my change proposal.)
>>> If you do keep it (and it's not too late in the process for editorial
>>> changes!), I would suggest adding a reference to CSS 2.1 section 10.4,
>>> where
>>> element sizing is defined more explicitly. That way, first-time readers
>>> will
>>> get that this part of the definition deals with something different than
>>> the
>>> other part. Such as:
>>> | 'contain'
>>> …
>>> | This will proportionally scale the used width and height up to the
>>> | given maximum constraints.
>>> + (See [CSS21] section 10.4 for more information on min/max constraints.)
>>> |
>>> | Set the concrete object size to the largest width and height that has
>>> …
>>> and similarly for 'cover'.
>> Fantasai, since you're the one of us who argued for this behavior, can
>> you confirm whether or not Leif is right, and the statement in Images
>> is redundant with the text from 2.1?  The special behavior implied by
>> those values was subtle enough that I didn't catch it until you
>> pointed it out, so I'm not confident whether I'll correctly recognize
>> what 2.1 says on the matter either.
> I'm having trouble loading it all in my brain in order to explain it, but
> IIRC it's sufficiently explained here:
>  http://lists.w3.org/Archives/**Public/www-style/2011May/0638.**html<http://lists.w3.org/Archives/Public/www-style/2011May/0638.html>
> ~fantasai
Received on Wednesday, 29 February 2012 16:21:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:12 UTC