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

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

From: Simon Pieters <simonp@opera.com>
Date: Thu, 27 Jan 2011 08:08:52 +0100
Cc: "www-style@w3.org" <www-style@w3.org>, Philip J├Ągenstedt <philipj@opera.com>, "Leif Arne Storset" <lstorset@opera.com>, "L. David Baron" <dbaron@dbaron.org>, "Erik Dahlstrom" <ed@opera.com>, www-svg@w3.org
To: "Simon Fraser" <smfr@me.com>
Message-ID: <op.vpygszxkidj3kv@simon-pieterss-macbook.local>
On Thu, 27 Jan 2011 07:11:52 +0100, Simon Fraser <smfr@me.com> wrote:

> On Jan 26, 2011, at 9:52 pm, Simon Pieters wrote:
>
>> 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).
>
> Can you be more specific about the cases where behavior would change by  
> having the default be 'fill'? Is it just the case of SVG with  
> preserveAspectRatio, as noted below? It would be good to see some  
> testcases here.

Bitmaps in <img> and <object> traditionally behave as 'fill', while SVG  
does not (even without preserveAspectRatio). "respect preserveAspectRatio"  
below is supposed to mean "repsect the preserveAspectRatio rules in the  
SVG spec even if that attribute is absent". Note that 'meet' is the  
default value for preserveAspectRatio, which is like object-fit:contain.  
If no viewBox is provided or can be synthesized, for <object> and <svg>  
the traditional behavior is like object-fit:none; object-position:top left.

See http://software.hixie.ch/utilities/js/live-dom-viewer/saved/807

Looking now, it seems that we still don't have interop in this area. IIRC,  
Opera is compliant with the SVG spec. Chrome seems to always use 'fill'  
for img and always cause an iframe-like effect for SVG in object. Firefox  
is more like Opera but disagrees with the no-viewBox case. There might be  
room to change the SVG spec if we can agree on what behavior we want here,  
if that is preferred over the 'auto' value.

A hard requirement of course is to use 'fill' for bitmaps in img. I would  
guess that it is also a hard requirement to use 'fill' for bitmaps in  
object. That means that if we want to use the same rules for SVG as  
bitmaps, SVG in img and object would also need to be treated as 'fill'  
(unless we decide that SVG in object should create an iframe-like element  
where object-fit doesn't apply).

cc-ing ed and www-svg since I'm not an expert on SVG and so could be  
proven wrong on the above.


> It also interacts with CSS 2.1 behavior for replaced elements with  
> intrinsic aspect ratio, so it's a tricky area.
>
>> At this time I don't recall exactly how the SVG spec ended up with  
>> interaction with object-fit, if at all. However, we implemented 'auto'  
>> as the initial value for object-fit as we suggested back then. (We made  
>> 'auto' map to 'contain' for video because back then we planned to make  
>> Ogg work in <object> something like as if it was <video controls>.  
>> We've dropped that plan but still make 'auto' map to 'contain' for  
>> <video>.)
>
> For this case, you could set video { object-fit: contain; } in your UA  
> CSS file, no?

Yes.


>> http://testsuites.opera.com/object-fit/README has an up-to-date  
>> description of our 'auto' value, quoted below:
>>
>> [[
>>
>> auto
>>    The initial value. Is used to retain backwards compatibility --  
>> traditionally bitmaps and SVG
>>    render differently in <object>, so to remain the status quo, a new  
>> value was needed.
>>
>>    Choose a method of scaling the content based on its type and  
>> element. The following table gives
>>    the rendering for each type:
>>
>>    Content         | Used value
>>    ----------------+---------------------------------------------------------------------
>>    bitmap          | -o-object-fit: fill
>>    ----------------+---------------------------------------------------------------------
>>    SVG in <img>    | synthesize a viewbox if none is specified (if  
>> possible ) and respect
>>                    | preserveAspectRatio
>>    ----------------+---------------------------------------------------------------------
>>    SVG in <object> | if a viewbox is provided, respect  
>> preserveAspectRatio; otherwise,
>>    or <svg> 	    | -o-object-fit: none; -o-object-position: top left
>>    ----------------+---------------------------------------------------------------------
>>    video           | -o-object-fit: contain
>>
>>    Viewbox synthesis is not possible when SVG width and height are  
>> specified as percentages.
>>
>>    When rendering SVG with the property -o-object-fit set to 'auto',  
>> the -o-object-position
>>    property is ignored, and SVG's own preserveAspectRatio attribute  
>> will take effect instead.
>>
>> ]]
>
>
> Simon


-- 
Simon Pieters
Opera Software
Received on Thursday, 27 January 2011 07:09:37 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:36 GMT