W3C home > Mailing lists > Public > www-style@w3.org > January 2011

Re: [css3-images] Reintroduce object-fit: none

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 26 Jan 2011 17:15:38 -0800
Message-ID: <AANLkTi=KHKL9PX0_p7hyUXSJC-NiOyn-OXsYTSZcCTAi@mail.gmail.com>
To: "L. David Baron" <dbaron@dbaron.org>
Cc: Leif Arne Storset <lstorset@opera.com>, www-style@w3.org, Philip Jägenstedt <philipj@opera.com>, "Simon Pieters (zcorpan)" <simonp@opera.com>
On Wed, Jan 26, 2011 at 4:50 PM, L. David Baron <dbaron@dbaron.org> wrote:
> On Wednesday 2011-01-26 11:50 +0100, Leif Arne Storset wrote:
>> I was asked recently whether and why 'object-fit: none' was removed
>> from the spec. Digging in the archives, it seems the proposal to
>> keep/revive it was forgotten amid other issues. So this is a request
>> to re-introduce 'none' as a value for 'object-fit'. The definition
>> would be "Render the content at its intrinsic dimensions,
>> overflowing if necessary."
>> The use case is easy centering or positioning images without scaling
>> them. Centering images vertically in a box can be a PITA today,
>> especially if you don't know the dimensions. With image-fit:none, it
>> is super-easy. Have a look at the attached demo (only supported in
>> Opera 11, AFAIK).
>> (To avoid any confusion: There were objections to our proposal of
>> another value, 'object-fit: auto', because the proposal was that
>> behavior depend on content type. These issues do not affect the
>> current proposal of 'object-fit: none', since no content-type
>> negotation takes place for 'object-fit: none'.)
> I think this is a bad idea.  (I think the 'object-fit: scale-down'
> proposal later in the thread, however, is fine.)
> The main things I don't like about it derive from the fact that it
> causes replaced elements to overflow.  I now see that
> object-fit:cover also does this, though I don't remember it doing
> that the last time I read the proposal.  I'd really like to avoid
> getting into a situation where overflow applies to replaced
> elements; I'd prefer that they just never overflow their content
> box.
> (It's also quite inconsistent with what we ended up doing
> about the interaction of border-radius and replaced elements, since
> the border-radius is supposed to clip replaced elements.  What
> happens with img { object-fit: cover; border-radius: 10px } ?)
> I think making it easy to overflow is generally a bad thing:  layout
> systems should make it easy for authors to do what they want in ways
> that don't accidentally cause horrible layouts in a slightly
> different situation (e.g., slightly different viewport size, font
> size, etc.).  Having an object-fitting mode that overflows by
> default fails this test (whereas 'scale-down' passes it).  This is
> why I'd prefer that replaced elements not overflow their content
> box.

So, you support removing 'cover' and 'none' entirely?  'cover' is
indeed designed to overflow *by default*.

Another option is to simply disallow the overflow effect at all - that
is, *always* hide overflow on replaced elements, and ignore the
'overflow' property.  That would solve your concern while still
allowing whatever use-cases 'cover' allows.  (I'm not sure why 'cover'
is useful, personally.)

> Furthermore, I think we need to be solving vertical centering for
> all elements, not just replaced elements.  We have some good
> proposals (including flexbox) on the table, and I hope they're
> implemented before 'object-fit' (which I think has substantially
> less demand than good layout systems) is.  So I don't think we
> should design 'object-fit' to solve use cases that should already be
> solved by the time it's implemented.

I agree.  If the only use-case for 'none' is centering an image,
that's not sufficiently useful to justify its existence.

> It's also unclear to me how much sense both 'none' and 'scale-down'
> make in a high-DPI world where CSS pixels mainly exist for
> backwards-compatibility.

Can you elaborate?  I'm not sure I understand the objection here.
Raster images still map their pixels to CSS pixels, unless you've
specified otherwise in 'image-resolution'.

Received on Thursday, 27 January 2011 01:16:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:55 UTC