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

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:
>>
>>
>> * overflow mismatch
>>
>> The spec is inconsistent with Basic Box Model Module (where overflow is
>> defined [1]). image-fit applies to replaced content, but depends on the
>> overflow property, which does not apply to replaced content.
>>
>> It seems simple enough to modify overflow to accept replaced content,
>> but note that overflow allows more values than just visible and hidden.
>> There are scrollbars and no-content/no-display bailouts. If these are
>> not desired, the image-fit spec should explicitly say so. However, I
>> suggest that we accept these values (and thus do not mention anything
>> about them in particular).
>>
>> Suggested change: In the Basic Box Model chapter on overflow, remove all
>> mentions of "non-replaced".
>
> Actually, last time I talked with Hyatt, he suggested we make overflow
> not apply: as in CSS2.1, replaced content should never overflow the
> content box. (Also, overflow clips to the padding box normally -- and
> here we're talking about the content box.)

We've implemented overflowing, at least for bitmap images. However I guess  
we could make it always be clipped if other implementors think that's  
better.

Personally I think it's a nice feature, even though it doesn't exactly  
match how overflow works elsewhere. A use case is e.g. a gallery with a  
grid of images using image-fit:contain normally and image-fit:cover on  
hover.


>> * 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?

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.


>> * Fit to content or padding box?
>>
>> Section 10.3 states that images are to be positioned relative to the
>> padding box; in the initial case ("image-fit: fill") this means that the
>> image covers the padding box. However, currently all browsers fit images
>> to their content box. Is the spec unintentionally going against current
>> practices, or am I missing something?
>>
>> Furthermore, both 10.2 and 10.3 rarely state which box they are talking
>> about. To me it seems like every instance of "box" should refer to the
>> content box, except the last normative paragraph of section 10.2; it
>> discusses overflow and probably should refer to the border box. Am I
>> correct in this assumption?
>>
>> I guess whoever wrote that copied stuff from 'background' and forgot to
>> check if it actually made sense... :-)
>
> Good point. It should be referring to the content box.
>
>> * Don't inherit
>>
>> Inheriting is problematic for SVG because the SVG author probably won't
>> expect all elements establishing new viewports to suddenly look
>> different. It is difficult to see what advantages there would be for
>> other replaced content, except perhaps multiple nested <object>  
>> fallbacks.
>>
>> Suggestion: Do not inherit image-fit and image-position.
>
> Yes, the original use case for inheriting was multiple nested <object>
> fallbacks. If this prevents SVG from mapping preserveAspectRatio to
> image-fit (or whatever we call it [1]) on the <svg> element itself,
> then I do not mind changing it.
>
>> * 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/
>
>> * 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
>
>
>> 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.

Hmm yeah.


> 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')
>    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.

-- 
Simon Pieters
Opera Software

Received on Thursday, 18 February 2010 08:01:49 UTC