W3C home > Mailing lists > Public > www-style@w3.org > March 2010

Re: [CSSWG] Minutes and Resolutions 2010-02-24

From: Erik Dahlstrom <ed@opera.com>
Date: Wed, 03 Mar 2010 19:48:04 +0100
To: "www-style@w3.org" <www-style@w3.org>
Message-ID: <op.u8z86esrgeuyw5@localhost>

The SVG WG discussed the image-fit/image-position properties briefly in  
our last telcon[1], here's some feedback from that.

On Fri, 26 Feb 2010 23:43:23 +0100, fantasai  
<fantasai.lists@inkedblade.net> wrote:

>    <fantasai>  
> http://lists.w3.org/Archives/Public/www-style/2010Feb/0164.html
>    fantasai: The "none' value is asserted as necessary for SVG. I am not  
> sure
>              that this is so.
>    fantasai: If CSS decides on the view box size and SVG decides how to  
> fill
>              it then there is no need for a 'none' value because SVG  
> setting
>              will be used anyway
>    ACTION (all) read Elika's answer above

The 'none' property value could be used as a way of telling SVG to respect  
the 'preserveAspectRatio' attribute (basically rendering as if  
image-fit/image-position were not implemented). Is there any other way of  
doing that?

>    wrt Don't inherit
>    Daniel: It is suggested to not inherit image-postition and image-fit
>    fantasai: the use case for inheritance is "nested object elements"  
> but it's
>              more important to match SVG's preserveAspectRatio
>    Simon: I am fine with no inheritance
>    Bert: me too
>    RESOLVED: Do what is best for SVG
>    N. B. if what is best for SVG involves no inheritance, then there  
> will be
>          no inheritance
>    ACTION (Elika): Find out what is best for SVG

Inheriting would be problematic for SVG because an SVG author probably  
wouldn't expect all elements that establish new viewports to suddenly look  
different. Take for example the case of nested svg elements.

>    wrt A new 'auto' behavior
>    Bert: I do not like it; I think we can do without it
>    Peter: how do we get the default behaviors without it
>    fantasai: We can say that we assign the box and the content "filler"  
> does
>              what ever it thinks is right
>    fantasai: using the model above, the content filler is given the size  
> of
>              the area to fill and it makes the decision on how to fill it
>    Sylvain: Would 'auto' be the default behavior then?
>    Answer: yes
>    dbaron: Because "object" is so hard to implement, perhpas we should  
> not
>            force that on every other kind of element
>    Sylvain and dbaron: auto should not be the default just because it is  
> good
>                        for "object"
>    Daniel: do you agree that a new "auto" value is needed?
>    <dbaron> I think <object> behavior might be a bunch of quirks... and
>             object isn't used very much for any of this.
>    <dbaron> I think the right behavior for <object> might be to switch
>             implementations to doing 'fill'.
>    Sylvain and dbaron: no, we do not agree there is a need
>    RESOLVED: the proposal for a new "auto" value is not accepted

There is general agreement in the SVG WG to allow image-fit/image-position  
to override 'preserveAspectRatio', and to use it for the elements where it  
makes sense, e.g <svg> and <image>. In doing so we would naturally like to  
avoid breaking existing content. If the image-* properties in any way  
changes the rendering when not explicitly specified then that's not good.  
The initial values should be chosen such that they describe current  
behaviour. An 'auto' value is one way of dealing with this complexity.  
There might be other ways too. In any case introducing the  
image-fit/image-position feature while at the same time breaking existing  
content (e.g svg content referenced by <object>) is not acceptable.

Furthermore the model that was presented in [2] isn't ideal for describing  
<svg:image>[3], since <svg:image> doesn't use the CSS box model and since  
it can reference SVG files with no intrinsic size. What's important in  
that particular case is to extract the referenced SVG's 'viewBox' (if it  
exists), since that's what should be fitted into the <svg:image> viewport.  
Also I don't think it fulfills the requirements for being called "replaced  
content". The <svg> element is similar in that it doesn't have a CSS box  
when it's nested inside another <svg> element. Only the <svg> that is  
actually laid out by CSS would have a CSS box, an example would be the  
case of an inline <svg> fragment in an HTML5 or XHTML document.


[1] http://www.w3.org/2010/03/01-svg-minutes.html#item05
[2] http://lists.w3.org/Archives/Public/www-style/2010Feb/0164.html
[3] http://www.w3.org/TR/SVG11/struct.html#ImageElement

Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed
Received on Wednesday, 3 March 2010 18:42:49 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:32 UTC