Tab Atkins Jr. <jackalmage@gmail.com> skreiv Thu, 27 Jan 2011 02:15:38
+0100
> 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).
>> 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.
Disallowing overflow is fine by me; I care more about the ability to
disable scaling. (My definition and rationale was just copy-pasted from
last year's proposal. I even used the old property name, 'image-fit'...)
>> 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.
In addition to Simon Pieters's demo elsewhere in the thread, I'll mention
an image viewer with Google Maps-style panning, where you'd like to
display an portion of an unscaled picture. I've attached a demo that works
in Opera (though my limited JS skills don't allow for mouse panning).
Also, the current situation for images is rather odd - the default is to
manipulate the image in a way that easily introduces distortion (by
scaling it independently along each axis). Simply displaying the unscaled
image in a sized box must be done server-side, with scripts or with
additional elements. Given the layout limitations of the early web, it's
not surprising that Netscape did it this way back then, and we can't
change the default now. But with 'object-fit: none' we can at least allow
the image to be presented unmanipulated - which would have been the
default under other conditions.
--
Leif Arne Storset
Core Technology Developer, Opera Software
Oslo, Norway