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

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

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

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

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.

~fantasai

Received on Wednesday, 17 February 2010 23:01:43 UTC