Re: Feedback on 'image-fit' and 'image-position'

fantasai <fantasai.lists@inkedblade.net> skreiv Thu, 18 Feb 2010 09:44:22
+0100

> Simon Pieters <simonp@opera.com> skreiv Thu, 18 Feb 2010 09:00:56 +0100
>
>> On Thu, 18 Feb 2010 00:01:06 +0100, fantasai  
>> <fantasai.lists@inkedblade.net> wrote:
>>
>>> On 01/21/2010 06:56 AM, Simon Pieters wrote:
>>>> Hi,
>>>>
>>>> Regarding image-fit and image-position:
>>>>
>>>> http://dev.w3.org/csswg/css3-page/#propdef-image-fit
>>>> http://dev.w3.org/csswg/css3-page/#propdef-image-posn
>>>>
>>>> We have the following feedback:
.
>>>> * Missing "none"
>>>>
>>>> The none value only seems to be documented in the example and is not
>>>> actually part of the property according to the current draft.
>>>>
>>>> Suggestion: In the image-fit definition [2], add "none" to the list of
>>>> values. In the description, add the following:
>>>>
>>>> none
>>>> Render the content at its intrinsic dimensions, overflowing if  
>>>> necessary.
>>>
>>> Hmm, the intention was to remove 'none', because we couldn't come up
>>> with a use case. Are you saying we should add it back?

No, we just didn't realize you wanted to remove it. But Simon's use case,

>> We've implemented it, and it seems useful for 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.

is relevant, so I'm thinking you should add it back.

>>>> * Move to another module
>>>>
>>>> In chapter 10, the spec states that [3]
>>>> The following properties may be transferred to a more appropriate CSS
>>>> module in the future.
>>>>
>>>> This makes sense, given that the property is not only useful for paged
>>>> media. One possible target might be the Generated and Replaced Content
>>>> module, in the chapter Replaced content. [4]
>>>
>>> Alternatively the css3-images module might be a good fit.
>>>    http://dev.w3.org/csswg/css3-images/

That module seems to be exclusively about image syntax, so I imagine
replaced content might be a better place. No big deal for me, though.

>>>> * New auto value
>>>>
>>>> WebKit, Gecko and Opera render SVG, bitmaps and videos differently in
>>>> <object>. Using any single value of image-fit would break this
>>>> compatibility. We suggest a new value auto that will maintain the  
>>>> status
>>>> quo.
>>>>
>>>> Suggestion: Under 10.2 The ‘image-fit’ Property, add "auto" to the  
>>>> list
>>>> of values. In the description, add the following:
>>>>
>>>> auto
>>>> Choose a method of scaling the content based on its type. The  
>>>> following
>>>> table gives the rendering for each type:
>>>>
>>>> Content | Scale as if image-fit:
>>>> --------+------------------------
>>>> bitmap | fill
>>>> SVG    | none
>>>> video  | contain

(note: this table is from our previous response and is outdated)

>>>> We found that for complete backwards-compatibility, image-position  
>>>> cannot
>>>> override preserveAspectRatio. Therefore we suggest to add the  
>>>> following
>>>> note in the description for the image-position property:
>>>>
>>>>     When rendering SVG with the property 'image-fit' set to 'auto',
>>>>     this property is ignored, and SVG's own preserveAspectRatio
>>>>     attribute will take effect instead.
>>>
>>> I'm not 100% clear on the interactions between SVG and the CSS-defined
>>> viewport here, so I'm not sure if this is correct. For one thing, if
>>> I specify 'image-position' on the <svg> element, and the SVG WG adopts
>>> image-fit and image-position as the property equivalents of the
>>> preserveAspectRatio attribute (which IIRC was the intent of the SVGWG
>>> at one point) that should work no problem.

Yes, if image-.* replace preserveAspectRatio in SVG the conflict between
them obviously will be removed. We still have to deal with backwards
compatibility though, and we may still want to discriminate based on media
type.

>>> My current mental model for the rendering of replaced content is the
>>> following:
>>>
>>>    1. CSS queries the object for its intrinsic size.
>>>    2. CSS computes the size of the CSS content box based on this info
>>>       and the CSS properties applied to the replaced element.
>>>    3. CSS adjusts the viewport for the replaced element:
>>>         - to match the size of the content box for image-fit: fill
>>>         - to cover the size of the content box while preserving the
>>>           intrinsic aspect ratio for image-fit: cover
>>>         - to contain the size of the content box while preserving
>>>           the intrinsic aspect ratio for image-fit: contain
>>>    4. CSS adjusts the position of the viewport with respect to the
>>>       content box according to the specified image-position.
>>>    5. CSS gives the object its viewport dimensions and asks it to  
>>> render.
>>>    6. The object renders into its given viewport according to its own
>>>       rendering rules. (For SVG, this could include accounting for
>>>       preserveAspectRatio. For videos, it could mean using 'content')

The model in step 6 would be simpler, but it would mean the CSS author
cannot really control the rendering of replaced content, and much of the
point of having an image-fit property is lost. For example, 'image-fit:
fill' would make no difference for video and SVG, who would continue to
preserve their aspect ratios (i. e. not fill the content box).

>>>    7. CSS clips any parts of the viewport that extend beyond the
>>>       content box.
>>>
>>> In the above mode, the only interaction between CSS and the replaced
>>> content is:
>>>    a. The replaced content reports its intrinsic size
>>>    b. CSS tells the replaced content the size of its viewport
>>>
>>> I think it's important for there to be no format-specific negotiation
>>> between the replaced content and CSS. The model should be defined so
>>> that SVG doesn't need any special exceptions. The rules in CSS should
>>> be able to handle <iframe> content, plugins, videos, bitmap images,
>>> SVG, <canvas> and any other replaced content the same way.
>>
>> Browsers have format-specific rules today. <object> can use different  
>> formats. Therefore, for compat, <object> needs format-specific rules.  
>> Hence the new 'auto' value.
>
> But does *CSS* need format-specific rules, or can those be handled in
> step 6? It seems to me they can be handled in step 6.

I do agree that such rules are a bad thing. However, the motivation for
'auto' is that current UA rendering is type-dependent, and we need to
specify that rendering should be backwards-compatible and what exactly
'backwards-compatible' means. Underspecification is probably a worse thing
than (limited) loss of spec cohesion.

There are a couple of alternate scenarios, but I'm not sure they would be
better:

First, one might imagine specifying this using a combination of

    * default style sheets ("img { image-fit: fill; } object { image-fit:
none; }")
    * SVG specification ("UAs may choose to synthesize a viewbox if one is
not specified") [1]
    * HTML specification ("<img> will synthesize a viewbox for SVG",
"<object> will not synthesize a viewbox for SVG")

However, that would leave SVG in <img> and bitmaps in <object> between
the cracks (SVG in <img> is rendered like 'image-fit: contain' whereas
bitmaps in <object> are rendered like 'image-fit: fill'), and HTML would
specify appearance, not just structure, and also be format-specific. It
seems to me that a format-specific CSS is the lesser of all these evils.

An alternative that might be workable in the long term would be to
introduce a CSS selector for the Content-Type header and a rule whether to
override an element's viewport or use its default. Something like

       img&image/svg+xml { viewport: default; /* image-fit is irrelevant */  
}
       object&image/svg+xml { viewport: default; }
       *&image/png, *&image/jpeg, *&image/gif { viewport: override;
image-fit: fill; }

This would be pretty complex, though, and it would be confusing that the
'viewport' property could disable 'image-fit' and 'image-position'. And it
would be a pretty long-term and involving proposition, and Selectors seems
to be pretty stable.

So all in all, we may have to consider being awfully pragmatic about this
issue and specify how to be backwards-compatible in CSS.

[1] http://www.w3.org/Graphics/SVG/WG/track/issues/2258
-- 
Leif Arne

Received on Friday, 19 February 2010 16:08:28 UTC