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

Re: [css3-images] Reconsider 'auto' value for object-fit

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 27 Jan 2011 13:46:55 -0800
Message-ID: <AANLkTikfAois8DaY+3hf95ZW=KRT98gM8bmOe3yZWN3i@mail.gmail.com>
To: Simon Pieters <simonp@opera.com>
Cc: "www-style@w3.org" <www-style@w3.org>, Philip J├Ągenstedt <philipj@opera.com>, Leif Arne Storset <lstorset@opera.com>, Simon Fraser <smfr@me.com>, "L. David Baron" <dbaron@dbaron.org>
On Wed, Jan 26, 2011 at 9:52 PM, Simon Pieters <simonp@opera.com> wrote:
> Hi
> I'd like the WG to reconsider the 'auto' value that we suggested as the
> initial value for object-fit back when we implemented object-fit. It's
> needed to retain backwards compatibility with traditional behavior of
> bitmaps and SVG in <img> and <object> as well as inline <svg>. I'm
> particularly interested in whether WebKit and Gecko would like to keep the
> status quo behavior for bitmaps and SVG in <img> and <object> (and <svg>) by
> using 'auto' or would rather like to change from the traditional behavior
> and make 'fill' the default, as the spec says (and probably breaking Web
> content that expects the traditional behavior, as well as changing from what
> the SVG spec requires for SVG, IIRC).

As stated by smfr, video doesn't need special-casing here, because the
UA stylesheet can simply supply a different object-fit value for
<video> via selectors.

<img> similarly works consistently.  The size of the drawing area is
always 'fill' by default.  SVG is then allowed to draw into that area
however it wants, including respecting the @preserveAspectRatio
attribute.  (Bitmaps just always scale themselves to the drawing

I forget exactly what the behavior of <object> is, but it should act
similarly, where it always figures out its drawing area in the same
way, and the content then decides how to fill the drawing area.

Received on Thursday, 27 January 2011 21:47:48 UTC

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