minutes, SVG WG Auckland F2F, day 4

Minutes in html format:


     http://www.w3.org/2011/03/02-svg-minutes.html


or as text below:


    [1]W3C

       [1] http://www.w3.org/

                                - DRAFT -

                    SVG Working Group Teleconference

02 Mar 2011

    See also: [2]IRC log

       [2] http://www.w3.org/2011/03/02-svg-irc

Attendees

    Present
           +1.649.363.aaaa, +1.425.868.aabb

    Regrets
    Chair
           SV_MEETING_CHAIR

    Scribe
           Cameron, Anthony, Jonathan Watt, Brian

Contents

      * [3]Topics
          1. [4]overflow auto
          2. [5]shorthand presentation attributes
          3. [6]Animation improvements
          4. [7]SVG 2 / CSS Filters Module
          5. [8]Intrinsic sizing
          6. [9]Automatic image sizing
      * [10]Summary of Action Items
      _________________________________________________________

    <trackbot> Date: 02 March 2011

    <birtles>
    [11]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animati
    on_improvements

      [11]  
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animation_improvements

    <birtles> Presentation: [12]http://brian.sol1.net/svg/pres/SVG 2
    Animation.html

      [12] http://brian.sol1.net/svg/pres/SVG

    <birtles> Presentation:
    [13]http://brian.sol1.net/svg/pres/SVG%202%20Animation.html

      [13] http://brian.sol1.net/svg/pres/SVG%202%20Animation.html

    <heycam> Scribe: Cameron

    <heycam> ScribeNick: heycam

overflow auto

    RO: the spec currently says that overflow:auto should be treated as
    visible
    ... that is incorrect
    ... in non SVG contexts, overflow:auto clips
    ... scrollbars if necessary, btu always clips
    ... for consistency, overflow:auto should be interpreted as clipping
    ... I don't think we should add scrollbars in SVG
    ... it's a pain
    ... we don't have that feature currently, don't want to add it now
    ... so we should make overflow:auto clip to be consistent with HTML

    ED: are the use cases for HTML and SVG different?
    ... for us, implementation wise it's cheaper to not clip
    ... but that's a detail
    ... in that sense I don't really care
    ... it makes it easier for people not to clip

    RO: auto is not the default value
    ... the default is visible
    ... so it only affects people who say overflow:auto
    ... people setting overflow:auto and expecting it to have no effect
    is unlikely

    DS: what about scroll?

    RO: the spec says treat it as hidden
    ... I'm saying treat overflow: auto, scroll, hidden all the same
    ... we provide scrollbars on the viewport
    ... but this is for a non-root element
    ... the root element is special

    DS: ah ok

    RO: css defines that, and we do that for svg
    ... which makes sense
    ... this is for non-root SVG elements

    CM: how does this relate to markers?

    ED: markers are overflow:hidden by default

    RO: so that would be totally unaffected

    ED: we probably need more tests around overflow

    RO: CSS is reinterpreting overflow as a shorthand for overflow-x and
    overflow-y
    ... if one of them is not visible, then the other one is treated as
    hidden
    ... so you can't clip in one axis only
    ... SVG should probably change that, but that's a separate issue
    ... so we need to add text to say that overflow: auto, hidden and
    scroll should all clip

    RESOLUTION: overflow:auto will be treated as hidden

shorthand presentation attributes

    CM: if overflow becomes a shorthand, then what happens to the
    overflow="" presentation attribute?
    ... we have rules to say that we don't have presentation attributes
    for shorthands
    ... I think that should change

    <scribe> ACTION: Cameron to write a proposal for allowing shorthand
    presentation attributes [recorded in
    [14]http://www.w3.org/2011/03/02-svg-minutes.html#action01]

    <trackbot> Created ACTION-2992 - Write a proposal for allowing
    shorthand presentation attributes [on Cameron McCormack - due
    2011-03-09].

    <anthony_nz> Scribe: Anthony

    <anthony_nz> ScribeNick: anthony_nz

    <birtles>
    [15]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animati
    on_improvements

      [15]  
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animation_improvements

    <birtles> Presentation:
    [16]http://brian.sol1.net/svg/pres/SVG%202%20Animation.html

      [16] http://brian.sol1.net/svg/pres/SVG%202%20Animation.html

Animation improvements

    BB: The presentation is pretty much the same as what's on the wiki
    ... The topic is "what we are going to do with SMIL"
    ... want to keep it high level
    ... and decide on what direction we want to head
    ... What are we trying to solve with declarative animation?
    ... The presentation is just to give some background
    ... for discussion later on
    ... the question is what we want to do with SMIL: drop it, patch it
    or something in between
    ... [goes through presentation]

    ROC: If you're creating the image from scratch, but if you want to
    import some other animated image and your tool doesn't understand
    the JS library that was used
    ... then you're stuck
    ... one thing that SMIL gives you is a standard vocabulary

    BB: The trouble is what tools
    ... and I don't think that hasn't been realised yet

    DS: We know we need tools for animation
    ... and that is going to emerge
    ... and it is important that we keep the facility in there to keep
    that interchange

    ED: Wanted to say something about the first point. There is small
    possibility to optimise things if you know what's going to happen in
    the document
    ... with script it is a bit more difficult
    ... in animation it is more possible to do some optimisations

    CM: There is probably still more chances for bridges between JS and
    animation
    ... have the timing done in the animation but have the values fed by
    script

    DS: That actually comes close to defining a script library defined
    by animation

    BB: [continues with presentation]

    DS: One thing that SMIL can't do is get the mouse position. So
    perform animation based on mouse position
    ... you frequently want to move something around with the mouse and
    you want to be able to do that declaratively

    BB: [Continues with presentation]
    ... [Slide: But SMIL isn't perfect...]
    ... [Slide: SMIL is complicated by syncbase timing]

    ED: Between fragments you mean between separate SVG files?
    ... I don't think it's defined in the spec or in CDF

    <ed> s/svg paths/svg fragments/

    BB: [Slide: SMIL is complicated by syncbase timing contd.]
    ... [Slide: Remove syncbase timing and replace with time containers]
    ... [Slide: SMIL 3 time containers - <par>]
    ... [Slide: SMIL 3 time containers - <excl>]
    ... [Slide: SMIL 3 time containers - nested contd.]
    ... [Slide: Wins]

    DH: What do you mean cancel the group?

    BB: If you have all these animations grouped together and you end
    that group then all the children will end as well
    ... so allows you to cancel that chain which you previously couldn't
    do
    ... so that's one of the advantages of having time containers and
    sync based timing
    ... [Slide: Challenges]
    ... [Slide: Challenges contd.]

    AG: You mean deprecating?

    BB: Might be a bit harsh, just say somethings don't work with the
    new containers

    DS: I basically deprecating, means we recommend don't using this
    feature

    BB: One of the issues with sync based timing you need to go through
    all the events when you do a seek
    ... we can keep event based timing, because that would allow you to
    do a lot of the current use cases

    DS: If you had them in the same time container, then you'd be
    guaranteed of syncronisation. I like that you can syncronise
    multiple resources
    ... then if event based timing doesn't guarantee that, then I'd be
    worried

    BB: You can still syncronise event based timing using a time stamp

    ED: Another point with sync based thing, is that if you have an SVG
    image would that impose some restrictions, because it's being
    suggested that eventbase timing wouldn't be allowed in svg-in-img

    BB: Some complex interactions would not be supported
    ... where two different elements can trigger the animation

    ED: There is a repeat event which is event based, but there's also
    repeat-value which isn't the same exactly as event-base

    BB: But it describes a qualified repeat event
    ... ... [Slide: Limiting the scope]

    CM: In SVG you use structure alot to control the rendering. If you
    introduce the containers control the timing

    BB: As it stands that is an issue, and you would need to redo where
    you are putting all your animations and all that

    DS: Bitflash based on one of their customers needs, added a state
    machine, I noticed one of the things you were going to talk about
    was reversing animations
    ... specifically they added SCXML
    ... the state machine was attractive because you could define how
    things interact under changed conditions
    ... if you're in this state do this thing, etc
    ... I authored to it and I found it very handy
    ... their extension of it would allow you keep the history of what
    had gone one
    ... navigating around a UI using the state machine would allow the
    reuse of animations
    ... it was completely declarative
    ... not sure where that fits with your proposal

    BB: There is a whole bunch of stuff in the SMIL state and I was
    thinking about that recently
    ... because I thought it would be good to be able to track state
    more

    DS: When we are talking about the animation use case, I think the
    state machine would be very useful for handling the sync for UI
    stuff
    ... I think we should take a serious look at it

    <heycam> [17]http://www.w3.org/TR/scxml/

      [17] http://www.w3.org/TR/scxml/

    BB: [Slide: Limiting the scope]
    ... [Slide: Structural manipulations need specification]
    ... not defined in SMIL so we need to

    DS: They didn't anticipate script

    CL: They were very much looking at authoring tools, because of the
    people involved
    ... One of the guys that really understands it has joined this
    working group now and he's interested in reworking it

    <ed> (15min break)

    BB: [Slide: Structural manipulations need specifications]

    <tbah> I'm done for the night so Patrick could dial in direct (it
    was a better connection than through the bridge).

    <pdengler_home> that's me

    <birtles>
    [18]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animati
    on_improvements

      [18]  
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animation_improvements

    <birtles> Presentation:
    [19]http://brian.sol1.net/svg/pres/SVG%202%20Animation.html

      [19] http://brian.sol1.net/svg/pres/SVG%202%20Animation.html

    BB: [Slide: Structural manipulations need specification]
    ... [Slide: Specify and test structural manipulations]
    ... [Slide: Discrete to-animation is counter-intuitive]
    ... [Slide: Fix discrete to-animation]
    ... [Slide: Frozen to-animation is broken]
    ... [Slide: The requirement for an end-instance time is confusing]
    ... Basically if doesn't find an end instance it just sits there

    AD: It never starts

    CM: Doesn't create the interval?

    BB: After that first interval it will never find the end time
    ... [Slide: Fix end-instance condition]
    ... [Slide: min/max aren't necessary useful]

    CM: Can you explain what the use cases are?

    BB: Just put a cap on the length on your child animations without
    knowing anything about them

    CL: If you have all these time animations and you want them to end a
    certain point then you specify the ending time for them
    ... then they all stop

    BB: [Slide: animateTransform]

    DS: One of the things I hate is the term "fill" on animations
    ... you had to determine by the context what "fill" meant

    CM: In CSS it is animation-fill-mode

    JW: What are the values?

    CM: Before, after, both
    ... both means to fill backwards before the animation
    ... the property value you can't understand it in isolation

    BB: [Slide: Reversing animations]

    CL: So you had the mouse over the button and it grew as big as it
    could then went back to the original size
    ... SMIL doesn't have this concept

    BB: [Slide: Add a reverse feature to time containers]

    JW: Maybe call it rewind?

    BB: [Slide: Add a reverse feature to time containers contd.]
    ... need to work out if want to do an ease in then an ease out or an
    ease in then an ease in going in reverse
    ... might need to do the exact reverse

    AD: I think that would be the logical thing to do
    ... running the clock backwards
    ... would need to work out how to specify it

    BB: [Slide: Re-use animations]
    ... [Slide: Re-use animations contd.]
    ... [Slide: Brief overview of SMIL Timesheets]

    CL: That would be really nice with :target

    BB: [Slide: Selectors can be nested]
    ... [Slide: Other features introduced by SMIL Timesheets]

    DS: Can I trigger something manually for when I'm making a
    presentation

    CL: You'd want two triggers in that case
    ... When the time hits or when I press the mouse

    BB: Not sure
    ... [Slide: Consider integrating SMIL Timesheets]

    CL: If you're animating class it's a discrete animation

    BB: Need to define how it all gets resolved
    ... [Slide: Migration path]

    CL: So the first one has a slight risks regarding confusions
    ... the second one is more what we are doing
    ... the third seems somewhat drastic but if we are combining SMIL
    and CSS animation then we are harmonising it
    ... At the end of the day it's also about animating HTML as well
    ... So I can see the third option as long as it does right

    DS: I think using the word SMIL is somewhat dangerous, because SMIL
    can mean different things to different people
    ... There is also the case where people will compare it to SMIL
    ... There are some people out there that dislike SMIL so it might
    not be as friendly to them
    ... If we are going to change it dramatically, I'm not sure the
    second way makes sense
    ... We could have backwards compatibility with SVG 1.1

    <pdengler_home2> I don't think I have been bashful about this. This
    is a great presentation. I believe we should focus on one animation
    engine/syntax. I thought this is what we exited Lyon with. Why would
    we continue to enhance something that no web developer is looking
    at? Let's take these ideas/proposals to CSS :)

    DS: One concern I have is as flawed as it is, and if we are going to
    reinvent the wheel we should be careful about what we do
    ... we may introduce new problems
    ... so we need to be careful about what we do with the new stuff

    <pdengler_home2> I don't disagree; just like in other areas
    (gradients, transforms, etc) this group has a lot of experience. We
    can contribute to a single effort and spread the knowledge more
    quickly.

    AD: In terms of web animations 1.0. One of the things we want to
    achieve is harmony between CSS and SVG. We take the things that we
    think are good in SMIL
    ... and add that to Web 1.0 along with the new stuff
    ... I'm not talking about breaking with the syntax, I'm talking
    about taking a subset
    ... and adding that to Web animation 1.0
    ... We kind of deprecate the SMIL stuff we say is not useful but
    provide better alternatives

    CL: It's a gradual already ramp up
    ... to a certain extent the process has already started
    ... it will be more widely available when we have first working
    draft

    DS: I am curious about time lines
    ... when do we realistically think this could be done
    ... I'd like to see some of this stuff in the next releases of web
    browsers
    ... these time lines are important

    <heycam> Scribe: Cameron

    <heycam> ScribeNick: heycam

    JW: if there are resources available in the css animation community,
    and those in smil, and can collaborate in the short term, maybe it
    can happen quickly
    ... but I don't know if that will happen

    AD: i really like the reverse stuff

    JW: i'm more concerned about if we're chopping up smil, or doing
    something else, we should do it pretty soon

    DS: i'm also concerned with having 3 major vendors here, with 1
    mobile vendor, all on the same page
    ... we don't have google/webkit people here
    ... authoring tool people?

    CL: authoring tool people would be unwise to start now, if we're
    going to change things
    ... unless you're right in the discussions

    DS: so they should participate in the discussions
    ... content creators, too

    <anthony_nz> Scribe: Anthony

    <anthony_nz> ScribeNick: anthony_nz

    <pdengler_home2> For this proposal, my key contributions are the
    scenarios and the properties/attributes that I think we need to
    animate to satisfy them.

    <pdengler_home2> My approach is to keep the list of
    attributes/properties constrained also to simple types so as to no
    introduce complicated interpolation issues.

    <ed>
    [20]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/CSS_Ani
    mation

      [20]  
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/CSS_Animation

    <pdengler_home2> This should is consistent with my original proposal
    last year to keep SVG 2.0 scenario and use case driven, and
    incremental.

    PD: This is to reduce complexity

    <pdengler_home2> Also, supports Jonathon’s desire to move quickly.

    <pdengler_home2> Further simplification attempts to avoid the
    discussion of animVal by using the CSS model.

    <pdengler_home2> Though there is a recommended proposal for
    promoting attributes to properties I was sufficiently convinced for
    good reasons why this is not a wise idea and these are indicate by
    Cameron here:
    [21]http://www.w3.org/Graphics/SVG/WG/wiki/Talk:F2F/Auckland_2011/CS
    S_Animation

      [21]  
http://www.w3.org/Graphics/SVG/WG/wiki/Talk:F2F/Auckland_2011/CSS_Animation

    <pdengler_home2> I like these proposals and could live with any that
    satisfy the scenarios put forth, and that don’t push us into a
    corner.

    <pdengler_home2> The key is to also recognize the imperative need to
    coordinate with the CSS working group. I’ve tried contacting Dean
    with this proposal but I do not believe I got a response.

    <pdengler_home2> As a group we should decide as to whether or not we
    should be doing this (obviously I think yes), if yes, then choose a
    model which does not paint us into a corner, and get it socialized
    quickly with CSS.

    PD: I believe my proposal doesn't quite work given Cameron's
    comments

    <heycam>
    [22]http://www.w3.org/Graphics/SVG/WG/wiki/Talk:F2F/Auckland_2011/CS
    S_Animation

      [22]  
http://www.w3.org/Graphics/SVG/WG/wiki/Talk:F2F/Auckland_2011/CSS_Animation

    CM: All this is based on that you should be able to use the CSS
    Animation syntax to target things which are currently not properties
    in SVG
    ... Section 1 presents a few different ways in achieving that goal
    ... Simplest on the surface would be to convert all these attributes
    we think are worth animating into properties
    ... then naturally they will animatable with CSS animations
    ... [Reads downsides from wiki]

    CL: The definition in CSS 2.1 is very precise for width and height
    ... could run into problems with inheriting

    CM: So this proposal is promoting to properties and using the exact
    names we have for attributes
    ... A major issue is that changes the distinction between attributes
    and properties
    ... There is a chance here to allow that sort of distinction to say
    which are styling attributes and which are presentation attributes

    CL: We were thinking about this and we'd ask what would make sense
    to re-style on a graphic
    ... geometry ended up being content in that way

    DS: One of the most important semantics about SVG is about how it is
    interpreted by accessibility agents
    ... and how SVG can be made accessible is not defined

    CM: The next point against this proposal is the whole SVG DOM
    interface

    ROC: We can have them reflect the CSS animated values
    ... and we can keep them

    CM: Another issue is which particular set of attributes we'd promote
    to properties
    ... in this proposal I think you should convert all the animatable
    attributes

    <pdengler_home2> The only objection I have to that is staging/timing

    CM: this is so we have the same functionality between CSS animations
    ... I think Patrick argument is starting with a smaller set is it is
    achievable goal

    <pdengler_home2> Interopolation is the item I worry about, but they
    may already be well specified with SMIL

    CL: If we do a certain subset and they don't scale across then we've
    painted ourselves into a corner
    ... If we were going to promote things to properties then we'd do
    them all at once

    <pdengler_home2> Either way we should nail the syntax that CSS
    animations and transitions need to pick up to target attributes and
    start there, yes?

    CL: but I still think that is a bad idea
    ... because it has a lot problems

    CM: This is probably the fundamental issue about how to target these
    attributes
    ... the biggest argument against this proposal is the names these
    attributes have
    ... we have attributes that have name as existing properties
    ... and we may limit CSS from expanding into certain areas

    CL: One of the other differences between properties and attributes
    ... is properties can apply to all elements
    ... so if we have a circle radius, it means that every element has a
    circle radius

    <pdengler_home2> Isn't that already the case with stop-color for
    example?

    CL: it's pointless to have a radius on all elements
    ... In CSS they want to restrict the property set
    ... so if look at proposals they normally choose the proposal that
    has the least number of properties

    ROC: We should actually check to see how many properties we have
    ... and what can be grouped together
    ... it is a lot of properties but you're adding more leverage to CSS

    DS: Some people want to do more of what we do in SVG in CSS

    <pdengler_home2> I thought it was generally agreed upon in Lyon that
    animating attributes in CSS was a goal. I agree that introducing
    more properties / aligning properties could take time. Could we
    start with attributes and worry about what’s a property and what
    does inheritance mean later (I realize this is against my proposal)

    CM: So there already are CSS properties that only apply to certain
    SVG elements
    ... and like wise for HTML
    ... Second proposal is the same as the first
    ... but giving new names

    CL: So it's really an alias

    CM: They are given unique names to avoid conflicts and short names
    e.g. "r"
    ... You could introduce a circle radius attribute to maintain
    consistency and say how they both work
    ... and secondly you could break the naming correspondence

    CL: I'd prefer to have a table that has the correspondence between
    the properties and the attributes
    ... I guess people may start putting it in as an attribute and
    wondering why it's not working

    CM: Third is to not do an promotion

    <pdengler_home2> Me too!

    CM: and make attributes animatable by CSS Animations

    <pdengler_home2> Yes, I changed my mind; I never came up with a
    syntax that worked but Cameron did.

    CM: The simple way is to just allow the attribute names where you
    can put property name inside the key sets
    ... then it's unclear if it's a property name or attribute name
    ... you're stepping on the namespace area again

    <pdengler_home2> YES! Perfect Chris!

    CL: CSS has rect { transition: (attr x) 0.5s; animation: a 0.5s both
    infinite }

    <AD> rect { transition: attr(x) 05.s ...

    <pdengler_home2> ship it

    ROC: attr() seems like the right thing to me
    ... because it's existing syntax and it's already there

    CM: Downside is the animation attributes is quite different about
    how you specify properties
    ... The third code snippet is a different proposal in this domain

    CL: How would you evaluate that one compared to attr()
    ... currently attr is used on the right hand-side of the ":"

    CM: I don't think CSS people would be happy with using that in
    normal rule sets
    ... These last few code snippets have the same idea
    ... Why do I prefer promoting properties - it seems less of a hack
    ... doesn't require new syntax
    ... I like the idea of extending the scope of properties
    ... the downside is quite a small set

    DS: I don't particularly care for the semantics argument
    ... the semantics argument is not a strong one in my opinion

    CM: If we can animate these things with CSS animations why wouldn't
    you want style these things regularly

    <pdengler_home2> Whether or not we want to style them, IMHO is a
    seperate argument. I don't want to style stdDeviation

    DS: Because of all the problems with promoting them to properties

    CM: Rest of the page is timing and interpolation functions and
    features that are missing
    ... and also how the sandwiches interact
    ... and a lot more so questions rather specific answers

    ROC: First of all, David Baron will be implementing CSS Animations
    in Gecko
    ... he's got a lot of knowledge in Transitions and Animations

    DS: So Chris do you predict any issues with putting attr on the
    left-hand side

    CL: Some

    ROC: In the context of animations it's doable
    ... in the context of actually doing it, it's probably not doable

    CL: It depends on why we would be doing this
    ... if the point is to get CSS Animation to work
    ... if the point is to style anything

    ROC: In the key frame stuff, it would work
    ... not for general stuff

    PD: Is this also Transitions?

    CL: Yes

    CM: So you don't have a problem with attr() on the left-hand side of
    the ":"
    ... because you need that for Transitions

    ROC: Why?

    CL: Transitions are triggered by certain things - changes attribute

    ROC: All Transitions says, when something changes make the change
    smooth

    CM: [Writes on the board]
    ... rect {transition: attr(x) 1s}
    ... rect: hover {attr(x): 50x}

    ROC: We shouldn't allow rect: hover

    CM: So you're saying that CSS Transitions can never change
    attributes
    ... Patrick do you have any thoughts about transitions not working
    CSS styled transition animations?
    ... the second rule is a straight style rule
    ... what if you change the x in the DOM
    ... would that cause a Transition?

    ROC: Yes

    DS: If you already have the underlaying model, then changing the
    parser to set up the model seems trivial

    CL: I agree
    ... it's the core animation stuff and how you do your display

    <pdengler_home2> so attr() works on transitions, animations and
    selectors?

    ROC: I would like to run it by David Baron

    ED: I will ask the people at Opera

    CM: The result of this discussion is that putting attr() in regular
    style rules on the left-hand side wouldn't work
    ... but the attr() in the Transition would still work

    <pdengler_home2> rect:hover{attr(x): 50px}

    PD: That's not supported?

    CL: Correct
    ... you'd thrash the DOM doing it that way

    CM: The work around is to make a CSS Animation
    ... because you can make the animation apply on the :hover
    ... We can discuss the proposal at the next FX call
    ... in two weeks

    <ed> next fx telcon will be in two weeks time

    CL: Get it finialised if we meet in June with CSS Working Group

    RESOLUTION: We prefer to use the attr() solution that allows CSS
    animations to target SVG attributes directly rather promoting
    attributes to properties

    <ed> (break for lunch)

    <pdengler_home2> I sent some of you an email with files to support
    our intrinsic sizing discussion. If I am late, please begin without
    me and I will catch up. See the agenda page for clear information
    about what we discovered.

    <pdengler_home2> Jonathan has been working on this for a while and
    shared his tests with all of us a long time ago.

    <pdengler_home2> We wanted to share some tests back and perhaps we
    can use them as a test bed for the test framework discussed on
    Monday.

    <pdengler_home2> We believe that these tests are accurate to the
    specification and where we believe the spec to be ambiguous, is
    within the spirit of the specification and/or interoperable.

    <pdengler_home2> So we can start with what we found
    ([23]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Intrin
    sic_sizing_tests) and I can post a test page with images.

      [23]  
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Intrinsic_sizing_tests)

    <pdengler_home2> For the tests, you will notice that indeed IE9
    passes all of them; this is because we used these tests to develop
    our platform.

    <pdengler_home2> As indicated on the email DL, after our latest
    platform preview we caught some sizing discrepancies between our
    implementation and the spec; we subsequently made adjustments

    <pdengler_home2> At the time of the change we aligned with Firefox
    beta. I think Firefox made adjustments for interop based upon our
    implementation (I think that’s what Rob said).

    <pdengler_home2> My apologies on this and my lack of communication
    on our last minute updates. They were fast and furious and as I
    promised these tests we want to contribute and believe that they
    accurately reflect the specification.

    <pdengler_home2> (be back shortly0

    <ed> i see that the examples patrick mailed out uses
    preserveAspectRatio="None" (caveat being that svg attributes are
    case-sensitive)

    <ed> the keyword value that is

    <ed> just one of the files: test_svg_viewbox_preserveratio.svg

    <jwatt> scribe: Jonathan Watt

    <jwatt> scribenick: jwatt

    BB: do we want a new spec for Web Animations, or to continue work on
    SVG animation?

    CM: so would Web Animations be an abstract spec about the model?

    DS: I think a single spec

    BB: I think we want this to apply to CSS properties in HTML, so have
    it separate to SVG

    CM: would that allow <animate> et. al. in HTML documents?
    ... or just have those elements being in SVG fragments but being
    allowed to target CSS properties in HTML documents?

    BB: defined in a way to allow HTML X to pull it in
    ... to target attributes if they wanted to do that

    DS: I think DOM bindings should be defined in that spec

    CM: separate spec sounds similar to the way we have separate SMIL
    specs now
    ... would it define elements that a host language can put it its own
    namespace?

    BB: I don't want to make in so abstract that we're not giving
    elements with names

    DH: it worries me slightly that we'll end up with four separate
    animation specs which people implement subsets of
    ... it seems like it might make more sense to keep in in the SVG
    spec

    s/in in/it in/

    scribe: to deserve the name "Web Animations" it would have to be a
    super-model to rule them all

    BB: getting CSS animations in the same spec

    DS: having a distinct and short name for the spec would have value
    ... I suggest we put something on paper as a single spec, try that,
    and split it if we have to

    ROC: first I want to get everyone together to figure out what
    browsers currently do with SMIL and CSS animation integration
    ... and transitions
    ... how they interact

    DS: it seems like the CSS stuff should override

    ROC: having CSS animations override SMIL animVals makes sense to me
    ... I would put everything in one spec

    DH: so scrap the CSS-animations spec its current incarnation?

    ROC: I think so

    <shepazu> s/so scrap the CSS-animations spec its current
    incarnation/so integrate the existing CSS animations spec into a
    single unified spec/

    <scribe> ACTION: Jonathan to Get Daniel to talk to David about
    making a new harmonized animations spec [recorded in
    [24]http://www.w3.org/2011/03/02-svg-minutes.html#action02]

    <trackbot> Created ACTION-2993 - Get Daniel to talk to David about
    making a new harmonized animations spec [on Jonathan Watt - due
    2011-03-10].

    RESOLUTION: Try to bring the existing declarative animation spec
    work together into a single spec, with separate sections for CSS
    animation and SVG animation

    <scribe> ACTION: Erik to bring up the one true animation spec on the
    fx call [recorded in
    [25]http://www.w3.org/2011/03/02-svg-minutes.html#action03]

    <trackbot> Created ACTION-2994 - Bring up the one true animation
    spec on the fx call [on Erik Dahlström - due 2011-03-10].

    <birtles> scribenick: birtles

    <scribe> Scribe: Brian

    <pdengler_home2> can't understand

    <pdengler_home2> Filters

    <pdengler_home2> How about filters

    <pdengler_home2> I have some text I wrote

SVG 2 / CSS Filters Module

    <pdengler_home2> are we all on the same chat now?

    <dholbert> I'm here

    <dholbert> heycam, can you see me? :)

    <heycam> ACTION: Cameron to bring up the
    CSS-animations-targetting-SVG-attribtues in the next FX telcon
    [recorded in
    [26]http://www.w3.org/2011/03/02-svg-minutes.html#action04]

    <trackbot> Created ACTION-2995 - Bring up the
    CSS-animations-targetting-SVG-attribtues in the next FX telcon [on
    Cameron McCormack - due 2011-03-10].

    <dholbert> (heycam says 'yes')

    <scribe> scribenick: birtles

    <scribe> Scribe: Brian

    ED: I did some updates to the filter spec

    <ed>
    [27]http://dev.w3.org/Graphics-FX/modules/filters/publish/SVGFilter.
    html

      [27]  
http://dev.w3.org/Graphics-FX/modules/filters/publish/SVGFilter.html

    I added some wording for handling filters applied to HTML thru CSS

    scribe: based on what roc wrote up
    ... taking part of the spec from Mozilla and integrating it into
    this filter spec

    <pdengler_home2> We need to distinguish what the filter is being
    applied to. From my simple understanding, the SVG Filters apply to
    graphical elements and paint underneath.

    <pdengler_home2> HTML “filters” (box-shadow, text-shadow) target
    different parts.

    <pdengler_home2> I suggest we add a ‘filter-target’ property to
    target different things (“box|text”) or (“content|whole”).

    PD: need to differentiate between targetting background content vs
    content itself

    <pdengler_home2> yes i can hear you

    RO: I think the best way to do that is to add new images
    ... right now you have SourceAlpha etc.
    ... ContentImage, ContentAlpha etc.

    ED: I added into the spec some wording in red about this

    RO: I don't think it's difficult to add new image names here

    ED: So what do we want to add Border? Background?

    RO: Border, Background, Outline are the 3 main ones
    ... Content would be everything else
    ... that includes everything their child can containa
    ... that would be really powerful, and easy to undersatnd
    ... let's do it

    ED: Does that map to something in SVG

    RO: no

    <ChrisL> s/containa/contain, including their borders and backgrounds

    CM: What are you thinking of?

    CL: Of those, SVG only has Content
    ... Content would apply to SVG and HTML equally

    PD: So I want to be able to only target the background of a table
    ... I want to take a SVG filter and target it to the text in this
    page, the background in another
    ... so it shouldn't be on the filter

    <pdengler_home2> filter-target="background"

    CM: So it should be on the property not the filter

    CL: But sometimes you want more than one

    CM: But for the simple case you only need one

    RO: one thing that's missing is how to interpret user space units

    <pdengler_home2> filter-target="border|background|content(default)"

    ED: it's there

    PD: I'm talking about targetting a div

    CM: we're talking about things (1) inside the filter introduce new
    filter primitive keywords (2) targetting a whole filter to only one
    aspect of a box

    s/about things/about two things/

    CL: there's always going to be a limit to what you can do with
    shorthand properties

    ED: keep the canned filters as simple as possible

    CM: I'd be happy with a feature like that

    PD: I agree
    ... the shorthand lets people doing something quickly
    ... but if you want to do something more complex you have to dig
    deeper
    ... and that's in a new spec where you start talking about new
    sources

    <pdengler_home2> So how do we get that to the CSS working group?
    Next FX call

    ED: Dino has an action to come up with the proposed syntax for the
    shorthands
    ... he's the co-editor of the spec
    ... it's moved to the public fx taskforce
    ... I'll get in touch with him to see how it's going

    <pdengler_home2> Sounds great, for my ability to track this can you
    create an issue on that

    ED: If he's too busy I'll propose something
    ... I'd like to remove the margin attribute
    ... and figure out the filter regions so we don't get clipping by
    default

    <pdengler_home2> All of this sounds great Eric

    ED: the margins were in the original SVG 1.1 which was suppose to
    address blur margins
    ... but all implementations are doing optimisations to address the
    slow cases anyway
    ... so they need to optimise the regions anyway

    CM: was there other stuff you'd like to rip out

    ED: they were the major things

    <pdengler_home2> I was going to say we clamp, but....we don't do
    filters...

    ED: the next step would be new filter primitive

    <ed> [28]http://www.w3.org/Graphics/fx/wiki/Filter_effects

      [28] http://www.w3.org/Graphics/fx/wiki/Filter_effects

    CM: experience shows explicit clamping in there didn't prove to be a
    useful optimisation
    ... people don't do it properly

    PD: if we were to do clamping it would be nice to have specific
    properties
    ... e.g. to what extent to you extend to infinite regions
    ... i'd like a story that says you can shoot yourself in the foot,
    but this is as far as you can go

    RO: can you give us an example?
    ... what are you talking about clamping?

    <pdengler_home2> i'm talking about clamping the combination of dx,
    stddeviation etc. don't worry

    <pdengler_home2> i prefer the margin proposal

    CM: we're talking about different things

    <pdengler_home2> Sorry

    ED: in those cases it might make sense to have limits
    ... although it needn't necessarily be in the spec
    ... but implementations should probably have limits

    CL: shorthand properties (canned filters) should say that here is an
    SVG filter that is equivalent
    ... but make clear you don't have to implement it like that
    ... as long as it has the same effect
    ... but authors shouldn't expect that SVG filter to show up in the
    DOM
    ... that allows hardware/platform acceleration to be used

    <pdengler_home2> Sure

    <ed> ED: could you explain a bit more about the point: "Support the
    inclusing of SVG <defs> as part of <link> in HTML"

    <pdengler_home2> <link rel=”import” type=”image/xml+svg”
    href=”file.svg”>.

    PD: I often end up with fairly large filters which I'd like to link
    externally

    CM: the current way you reference filters is in this way: url #
    something

    <pdengler_home2> <link rel="import" type="image/xml+svg"
    href="file.svg">.

    <ChrisL> url()

    <pdengler_home2> <filter="url(svg1.svg#mydef)"

    ED: how does import work?

    PD: it's difficult to import gradient, image definitions

    RO: you can reference all of those with URL # references
    ... what's wrong with that?

    PD: i don't have a bit complaint

    s/bit/big/

    RO: there's one situation: people writing stylesheets would like to
    reference filters without requiring yet another document
    ... one proposal is allowing CSS to contain XML
    ... so you can put the filter directly in the stylesheet
    ... I don't think it's a bad idea
    ... but for now the URL syntax seems to work

    PD: yeah, that makes sense
    ... let's leave it

    CL: in SVG we were very careful to use URI refs rather than ID
    ID-refs
    ... since that doesn't work for other docs
    ... so it gives us flexibility to address that

    ED: in this draft here I have one filter primitive that's not
    defined yet
    ... feCustom
    ... it's for defining shaders with SVG filters
    ... one possible way is to allow people to write filter primitives
    with open CL
    ... or perhaps WebGL
    ... it's lower level but gives you a lot of power

    CL: previously we proposed javascript callbacks for this

    ED: that would be slow

    CL: yeah, so this looks like more practical

    ED: so do you want to allow software-only engines to run shaders?

    PD: before we go to far down this path... is WebGL going to be
    brought into the W3C

    ?

    RO: WebGL may not be W3C but it is a standard

    <pdengler_home2> Is webgl under the same patent policy as w3c?

    <ChrisL> [29]http://en.wikipedia.org/wiki/WebGL

      [29] http://en.wikipedia.org/wiki/WebGL

    RO: on any platform that can run WebGL you should be able to use
    WebGL in a shader

    ED: could be a feature string
    ... so if you can run this, do this, otherwise do that

    CL: or we could use another language feature

    DS: what's the license?

    RO: not sure
    ... but the Chronos group has dealt with IP a lot

    <heycam> s/Chronos/Khronos/

    ED: so if we do that it would be good to pull into filter input
    images
    ... and integrate with the rest of the filter spec

    <ChrisL> [30]http://en.wikipedia.org/wiki/HLSL

      [30] http://en.wikipedia.org/wiki/HLSL

    ED: means some definition of how it integrates with the shader
    language

    <ChrisL>
    [31]http://en.wikipedia.org/wiki/Cg_%28programming_language%29

      [31] http://en.wikipedia.org/wiki/Cg_%28programming_language%29

    ED: how SVG filters integrate
    ... otherwise you could have just the shader and some fallback

    CM: so you want 1/2 inputs just like you do with filter primitives?

    ED: what does the shader look for?

    CM: mapping from the SVG buffer to whatever the shader takes

    ED: same for the output from the shader too

    CL: Cg lang can output different types of shaders
    ... so it could provide different shaders depending on the platform

    RO: Google provide ANGLE

    <pdengler_home2> "almost native"

    PD: will you pull that stuff out in the next week or so?

    <ChrisL>
    [32]http://code.google.com/p/angleproject/issues/detail?id=35

      [32] http://code.google.com/p/angleproject/issues/detail?id=35

    ED: in the coming weeks

    CL: I want some language in the spec about the canned effects
    ... that you don't actually need the equivalent SVG in the DOM as
    long as you get the same result

    <pdengler_home2> Did we solve the issue I brought up before with
    filter-target on HTML elements?

    <scribe> ACTION: Erik to work on removing the margins and put some
    proposed text for how to deal with the proposed filter regions into
    the filters spec [recorded in
    [33]http://www.w3.org/2011/03/02-svg-minutes.html#action05]

    <trackbot> Created ACTION-2996 - Work on removing the margins and
    put some proposed text for how to deal with the proposed filter
    regions into the filters spec [on Erik Dahlström - due 2011-03-10].

    <scribe> ACTION: Erik to follow up Dino about the shorthand syntax
    for filter effects [recorded in
    [34]http://www.w3.org/2011/03/02-svg-minutes.html#action06]

    <trackbot> Created ACTION-2997 - Follow up Dino about the shorthand
    syntax for filter effects [on Erik Dahlström - due 2011-03-10].

    <ChrisL> actually [35]http://code.google.com/p/angleproject/ is a
    better pointer for angle

      [35] http://code.google.com/p/angleproject/

    <pdengler_home2> my phone failed

    <pdengler_home2> I don't have my machine configured

    <pdengler_home2> to check into W3C

    <pdengler_home2> I emailed them, can someone please do that for me
    (my apologies)

    <pdengler_home2> (Did you get them in email?)

    <pdengler_home2> Ok I will get another phone and meet back after
    your break

    <ChrisL> s/yes we did/yes at least erik did and he is checking them
    in/

    <ed>
    [36]http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/svg_size/svg_size.
    html

      [36]  
http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/svg_size/svg_size.html

    <dholbert> pdengler_home2, so it looks like your page ^ is pairs of
    [svg testcase] [raster expected-rendering], right?

    <pdengler_home2> *should* be a test with the expected rendering next
    to it in a raster format

    <pdengler_home2> we overloaded the server with .5MB? :)

    <scribe> scribenick: birtles

    <scribe> Scribe: Brian

Intrinsic sizing

    <pdengler_home2> Jonathan has been working on this for a while and
    shared his tests with all of us a long time ago.

    [37]http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/svg_size/svg_size.
    html

      [37]  
http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/svg_size/svg_size.html

    ED: I've made some fixes (doctype, preserveAspectRatio="none" <--
    lowercase "none")

    <jwatt>
    [38]http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/svg_size/svg_size.
    html

      [38]  
http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/svg_size/svg_size.html

    <ed> (for completeness, here are the unmodified files from patrick:
    [39]http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/svg_size-patd-orig
    inal/svg_size.html )

      [39]  
http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/svg_size-patd-original/svg_size.html

    <pdengler_home2> We wanted to share some tests back and perhaps we
    can use them as a test bed for the framework discussed on Monday.

    <pdengler_home2> We believe that these tests are accurate to the
    specification and where we believe the spec to be ambiguous, is
    within the spirit of the specification and/or interoperable.

    <pdengler_home2> For the tests, you will notice that indeed IE9
    passes all of them; this is because we used these tests to develop
    our platform.

    <pdengler_home2> As indicated on the email DL, after our latest
    platform preview we caught some sizing discrepancies between our
    implementation and the spec; we subsequently made adjustments.

    <pdengler_home2> At the time of the change we aligned with Firefox
    beta. I think Firefox made adjustments for interop based upon our
    implementation (I think that’s what Rob said).

    <pdengler_home2>
    ([40]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Intrin
    sic_sizing_tests)

      [40]  
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Intrinsic_sizing_tests)

    PD: Let's see if we can agree on what the spec says, or if the tests
    are wrong

    JW: I think the 7th and 8th images are not being sized correctly on
    IE

    <jwatt> JW: "SVG sizing with 'viewbox' specified while 'width' and
    'height' is percentage inside an 'object' tag."

    JW: the 4th set of images
    ... from my understanding, the object element ends up with width
    50%, height: auto because the containing block, the body, has height
    auto
    ... which gets you to section 10.6.2 of CSS 2

    <jwatt>
    [41]http://www.w3.org/TR/CSS21/visudet.html#inline-replaced-height

      [41] http://www.w3.org/TR/CSS21/visudet.html#inline-replaced-height

    <jwatt> JW: Otherwise, if 'height' has a computed value of 'auto',
    and the element has an intrinsic ratio then the used value of
    'height' is:

    <jwatt> JW: (used width) / (intrinsic ratio)

    JW: since the height is not resolvable you end up using the
    intrinsic dimensions of SVG (100x100) --> ratio 1:1
    ... so the height of the object tag should be given the same
    computed value as its width
    ... so you should end up with square

    s/square/a square/

    PD: so firefox ends up with a square on this one?

    JW: previously you might have been testing firefox in quirks mode
    ... but if you run the test again you'll see it is a square in
    firefox

    PD: Erik, what's your interpretation

    ED: Jwatt is probably right
    ... what does the P1, P2, P2 mean in the wiki page

    PD: ignore that

    <jwatt> RRSAgent: make minutes

    ED: The P3 might have only been wrong because of the capitilisation
    of preserveAspectRatio

    PD: do you agree with jwatt's assessment that it should be 1:1

    ED: yeah, I think so

    PD: what does Opera do?

    DH: Opera matches the bitmap on my computer

    PD: it's the same as IE9 on my computer

    DH: could it be that they're using the viewBox to generate an aspect
    ratio?
    ... in this case there's a width and a height

    ED: jwatt is probably correct here
    ... I think the spec says the width/height takes precedence in this
    case
    ... and viewBox is used if there's no width/height

    <pdengler_3> My understanding is that the viewBox would take
    precidence as the percentage is 100% correct?

    <dholbert> height/width are both 100px

    JW: I'm pretty sure I'm right

    <dholbert> there's no percentage 100%, IIUC

    CL: 1.1F2 should have the same wording as Tiny

    ED: so width/height should have precedence

    PD: I want to make sure we're on the same page and it seems Erik and
    Jonathan are agreed
    ... I think this would be a good set of tests to formalise
    ... into the test bed
    ... where else do you think our interpretation might be incorrect?
    ... bear in mind that these tests are hot off the press

    <jwatt> JW: I think FF currently handles "SVG sizing without
    'viewbox' specified while 'width' and 'height' is percentage inside
    an 'object' tag." incorrectly

    <dholbert> I agree

    JW: it doesn't override the width/height on the SVG tag

    <ed> "SVG sizing with 'viewbox' specified while 'width' and 'height'
    is percentage inside an 'object' tag."

    ED: the first example says the width/height is % but the test case
    doesn't use % -- was the test case wrong
    ... oh it refers to the object element

    <pdengler_3> Eric, do you mean the very first test?

    <ed>
    [42]http://dev.w3.org/SVG/profiles/1.1F2/publish/coords.html#Intrins
    icSizing

      [42]  
http://dev.w3.org/SVG/profiles/1.1F2/publish/coords.html#IntrinsicSizing

    ED: yes, so I just wasn't sure where the percentages were, but it's
    ok
    ... So, is Firefox's handling of the first case is incorrect?

    JW: no not the first case

    <jwatt> JW: "SVG sizing without 'viewbox' specified while 'width'
    and 'height' is percentage inside an 'object' tag." - half way down
    the page

    <ed> ED: sorry, misread it, a bit confused by the similar text
    descriptions

    JW: So those are the only two cases I would point out

    DH: Looks like we match the reference on everything else

    <pdengler_home5> Ok, and that's the same issue as the 4th one right?

    ED: you mean just the SVG part, not the dotted lines

    DH: I mean including the dotted lines
    ... but ignoring the padding

    JW: Are the images supposed to match in size and position as well?

    PD: I believe Opera had some differences with the stylesheet

    JW: In IE9 after adding the doctype the rendering and bitmaps don't
    seem to be the same

    <pdengler_home5> That' because we made changes since PPB7 in RC to
    match Firefox :)

    <pdengler_home5> and the spirit and letter of the spec (I hope)

    PD: They all match for me on my build

    <pdengler_home5> SVG sizing without 'viewbox' specified while
    'width' and 'height' is percentage inside an 'object' tag."

    JW: Mozilla needs to fix that

    DH: Firefox does that incorrectly

    <pdengler_home5> The only issue is then that we have #4 incorrect

    <pdengler_home5> (aside from the preserveAspectRatio casing)

    JW: For the examples on this page, the first one I pointed out you
    don't do correctly, but the second one you and Opera do correctly
    and Mozilla does not

    ED: I think we should try to forward this to the WebKit guys
    ... our next step would be to try to collect these test cases into a
    test framework
    ... but it sounds like we're mostly on the same page

    PD: maybe contact with WebKit will really get us online

    JW: on the wiki page, under Firefox 4 there are 5 bullet points
    ... referring to the third one
    ... I think this is the correct thing to do
    ... did you remove viewBox logic?
    ... talking about it in terms of a viewBox is just to get the
    desired result
    ... to give the same effect as for raster images

    The point in question is "Next Firefox 4 beta will have Opera’s
    <img> viewBox logic."

    DH: I think the problem is when you have a non-percent width/height
    and NO viewbox
    ... we've changed it to synthesize a viewBox in that case

    <pdengler_home5> I think we all recognize that this is probably
    desirable, but I definitely want to raise the issue that injecting a
    missing attribute might be considered "quirks"

    DH: that's what Opera does
    ... this is for scaling
    ... the straightforward thing to do is to clip but what Opera does
    and what we think authors expect is to have the image scale
    ... like with a raster image
    ... an author can add a viewBox to get that behaviour
    ... but authoring tools generally don't do that

    CL: but then you can't get the image to be the size you desire
    anymore

    JW: if that's what you want just put width/height auto on your image
    tag

    DH: it's only when the SVG width/height doesn't match the image
    width/height

    <pdengler_home5> That was our concern; it may make sense, but it is
    assuming an attribute that is not there

    DH: we do it on the image tag, list style image (CSS images), but
    not on the SVG:image tag because it's well defined there

    ED: we don't do it there either

    DS: Tab Atkins wrote on www-style that he found the intrinsic sizing
    discussion a bit confusing
    ... we sorted out what was confusing him -- it wasn't clear to him
    that the SVG canvas extended infinitely on all sides
    ... he thought we could make that more clear
    ... and that if we talked about % width/height as a transformation

    CL: it's fairly easy to explain
    ... e.g. 30% each transform="scale(0.3)"

    DS: I thought it would be harmless to explain in those terms

    <scribe> ACTION: Doug to add some additional clarification to the
    intrinsic sizing part of the spec [recorded in
    [43]http://www.w3.org/2011/03/02-svg-minutes.html#action07]

    <trackbot> Created ACTION-2998 - Add some additional clarification
    to the intrinsic sizing part of the spec [on Doug Schepers - due
    2011-03-10].

    CL: (re Patrick's concern about the "quirk" of adding a viewBox
    attribute)

    DH: it doesn't match object

    PD: it doesn't match the spec

    DH: it doesn't match the spirit of the spec

    CL: is there anything in the HTML spec regarding this behaviour for
    PNG images etc.
    ... we could see if we're consistent with that

    DH: I'm sure it's in the CSS spec for raster images / replaced
    elements
    ... but I think a lot of the CSS spec text about this stuff doesn't
    expect images that react to their viewport

    JW: the bottom line is that without this viewBox insertion behaviour
    is unexpected for authors

    <ChrisL> until recently, that was certainly true

    JW: with this they get what they expect

    PD: I'm not sure, it's tough

    <jwatt> JW: some very loose spec text that daniel and I came up with
    while trying to get images to behave as authors expect: "for
    SVG-as-an-image, if the /embedding/ element doesn't implement
    preserveAspectRatio and the root <svg> in the image doesn't have a
    viewBox, resolve the <svg>'s width/height to pixels values and use
    viewBox="0,0,resolvedwidth,resolvedheight" and
    preserveAspectRatio=none...

    <jwatt> ...(ignoring any preserveAspectRatio on the <svg>)"

    DH: I acknowledge our current behaviour makes me uncomfortable given
    the lack of clarity in the spec
    ... I'd be more comfortable if we had something in the spec

    PD: it does say that for image
    ... but not when used as an <img>

    DH: the SVG image has different behaviour than the HTML <img>
    element for raster images
    ... so it's not unexpected that it would be different for SVG images
    either

    CL: Well we shouldn't define it in terms of faking a viewBox, but
    rather by analogue with raster images

    JW: maybe we can express it in terms of inserting an extra transform
    ... actually that's what we do
    ... we talk about viewBox to make it easier for an author to
    understand

    CL: if an image has an intrinsic size / fixed size and you want to
    make it bigger
    ... for raster images you scale it up
    ... and same for SVG but it just happens to scale nicely
    ... it's not SVG, it's about CSS replaced content
    ... it has an intrinsic size and we scale it up because the context
    in which it's being used says to

    DH: but you can find tune that scaling with a viewBox and
    preserveAspectRatio
    ... that's why we "add a viewBox"

    s/find tune/fine tune/

    JW: we'd say more than just scaling, but some other wording that
    didn't mention "viewBox"
    ... which will be more complicated but avoids talking about fake
    viewBoxs

    ED: as long as we get the same behaviour
    ... I think jwatt's text is more clear

    <scribe> ACTION: Patrick to consider intrinsic sizing behavior
    (particularly when a viewBox is not provided) and follow-up test
    cases [recorded in
    [44]http://www.w3.org/2011/03/02-svg-minutes.html#action08]

    <trackbot> Created ACTION-2999 - Consider intrinsic sizing behavior
    (particularly when a viewBox is not provided) and follow-up test
    cases [on Patrick Dengler - due 2011-03-10].

    <jwatt> JW: another set of tests for sizing:
    [45]https://jwatt.org/svg/tmp/embedded-sizing/embedded.html

      [45] https://jwatt.org/svg/tmp/embedded-sizing/embedded.html

    JW: we seem to diverge widely on these tests

    ED: can we put these in the UA sizing?

    JW: yes
    ... Patrick, those tests seem to show that IE's implementation of
    the CSS replaced elements stuff seems wrong
    ... especially further down where everything just collapses to
    nothing
    ... we've run out of time to talk about individual ones there
    ... but if you disagree with our implementation on any of those can
    you get back to me and I'll explain

Automatic image sizing

    JW: currently the SVG <image> tag if you don't specify width/height
    they default to 0 and nothing is shown
    ... they're required
    ... no way to get the width/height to automatically resize to the
    image you're embedding
    ... we should do what CSS embedding algorithm
    ... but simpler
    ... one or both of width/height can be specified and we determine
    the width/height

    CL: is this for SVG 2nd ed or 2?

    JW: SVG2
    ... I'd like the attributes to be optional
    ... we use the image aspect ratio to calculate the width/height

    DS: it's a breaking change

    CL: only if you're linking to images without specifying width/height

    DS: which I've done

    JW: I think the value of this is high enough that we should just go
    ahead and do this

    <ChrisL> DS: I did that to force preload of images

    <ChrisL> JW: Use visibility: hidden in future

    CM: I can imagine someone relying on that behaviour because they're
    going to animate it out
    ... (i.e. relying on it becoming 0, 0)

    DS: I usually make the attributes 0, 0
    ... this does break the idea of a rect with no width/height is 0,0

    JW: but rectangles don't embed resources

    DS: I think your rationale is perfectly reasonable
    ... I think this will be much more user-friendly

    CM: I agree
    ... is this for rasters and SVGs?

    JW: anything that can be embedded by an image tag that has an
    intrinsic size

    DS: how about an SVG with % width/height
    ... would it act the same as an HTML img element?

    JW: yes, but I need to look into it
    ... I want to simplify what CSS is doing

    ED: what does Tiny say about %s, are they intrinsic?

    s/ED: what/JW: what/

    JW: I don't particularly like the idea of resources that don't know
    what they're getting put into

    <scribe> ACTION: Jonathan to come up with text for automatic image
    sizing [recorded in
    [46]http://www.w3.org/2011/03/02-svg-minutes.html#action09]

    <trackbot> Created ACTION-3000 - Come up with text for automatic
    image sizing [on Jonathan Watt - due 2011-03-10].

    <ChrisL> kiriban!

    RESOLUTION: For SVG <image> missing an explicit width/height we will
    take in account the intrinsic dimensions/aspect ratio of the
    resource being embedded

    ED: this is not just for image
    ... there's feImage and potentially other places
    ... animation element

    DS: so bbox will clearly get the width/height

    <ed> foreignObject too

    DS: however, what about getting the attribute
    ... 0? null? undefined?

    CM: you'd get empty
    ... it wouldn't affect the DOM
    ... it should do whatever we do for other automatic values

    ED: currently we'd just create an object on the fly for cases like
    that

    DS: if you change the href if would also change
    ... do we need to put that in the spec?

    <ed> s/cases like that/cases like image without width, and you tried
    to fetch image.width.baseVal.../

    JW: I don't think that's necessary but it might be helpful as a note
    ... but you should apply the same rule with a new image

    DS: "even if the resource should change"

    <ed> trackbot, end telcon

Summary of Action Items

    [NEW] ACTION: Cameron to bring up the
    CSS-animations-targetting-SVG-attribtues in the next FX telcon
    [recorded in
    [47]http://www.w3.org/2011/03/02-svg-minutes.html#action04]
    [NEW] ACTION: Cameron to write a proposal for allowing shorthand
    presentation attributes [recorded in
    [48]http://www.w3.org/2011/03/02-svg-minutes.html#action01]
    [NEW] ACTION: Doug to add some additional clarification to the
    intrinsic sizing part of the spec [recorded in
    [49]http://www.w3.org/2011/03/02-svg-minutes.html#action07]
    [NEW] ACTION: Erik to bring up the one true animation spec on the fx
    call [recorded in
    [50]http://www.w3.org/2011/03/02-svg-minutes.html#action03]
    [NEW] ACTION: Erik to follow up Dino about the shorthand syntax for
    filter effects [recorded in
    [51]http://www.w3.org/2011/03/02-svg-minutes.html#action06]
    [NEW] ACTION: Erik to work on removing the margins and put some
    proposed text for how to deal with the proposed filter regions into
    the filters spec [recorded in
    [52]http://www.w3.org/2011/03/02-svg-minutes.html#action05]
    [NEW] ACTION: Jonathan to come up with text for automatic image
    sizing [recorded in
    [53]http://www.w3.org/2011/03/02-svg-minutes.html#action09]
    [NEW] ACTION: Jonathan to Get Daniel to talk to David about making a
    new harmonized animations spec [recorded in
    [54]http://www.w3.org/2011/03/02-svg-minutes.html#action02]
    [NEW] ACTION: Patrick to consider intrinsic sizing behavior
    (particularly when a viewBox is not provided) and follow-up test
    cases [recorded in
    [55]http://www.w3.org/2011/03/02-svg-minutes.html#action08]

    [End of minutes]
      _________________________________________________________


     Minutes formatted by David Booth's [56]scribe.perl version 1.135
     ([57]CVS log)
     $Date: 2011/03/03 04:18:26 $
      _________________________________________________________

      [56] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
      [57] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

    [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20
Check for newer version at [58]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/

      [58] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/paths/files/
FAILED: s/svg paths/svg fragments/
Succeeded: s/do a sync/do a seek/
Succeeded: s/would that impose some restrictions/would that impose some
  restrictions, because it's being suggested that eventbase timing would
n't be allowed in svg-in-img/
Succeeded: s/There is a repeat event which is event based/There is a re
peat event which is event based, but there's also repeat-value which is
n't the same exactly as event-base/
Succeeded: s/... [Slide: Add a reverse feature to time containers]/BB:
[Slide: Add a reverse feature to time containers]/
Succeeded: s/"r'/"r"/
Succeeded: s/Barron/Baron/
FAILED: s/in in/it in/
FAILED: s/so scrap the CSS-animations spec its current incarnation/so i
ntegrate the existing CSS animations spec into a single unified spec/
FAILED: s/containa/contain, including their borders and backgrounds/
FAILED: s/about things/about two things/
FAILED: s/bit/big/
FAILED: s/Chronos/Khronos/
FAILED: s/yes we did/yes at least erik did and he is checking them in/
FAILED: s/square/a square/
FAILED: s/find tune/fine tune/
FAILED: s/ED: what/JW: what/
FAILED: s/cases like that/cases like image without width, and you tried
  to fetch image.width.baseVal.../
Found Scribe: Cameron
Found ScribeNick: heycam
Found Scribe: Anthony
Found ScribeNick: anthony_nz
Found Scribe: Cameron
Found ScribeNick: heycam
Found Scribe: Anthony
Found ScribeNick: anthony_nz
Found Scribe: Jonathan Watt
Found ScribeNick: jwatt
Found ScribeNick: birtles
Found Scribe: Brian
Found ScribeNick: birtles
Found Scribe: Brian
Found ScribeNick: birtles
Found Scribe: Brian
Scribes: Cameron, Anthony, Jonathan Watt, Brian
ScribeNicks: heycam, anthony_nz, jwatt, birtles

WARNING: Replacing list of attendees.
Old list: +1.649.363.aaaa tbah
New list: +1.649.363.aaaa +1.425.868.aabb +1.649.363.aacc


WARNING: Replacing list of attendees.
Old list: +1.649.363.aaaa +1.425.868.aabb +1.649.363.aacc
New list: +1.649.363.aaaa

Default Present: +1.649.363.aaaa, +1.425.868.aabb
Present: +1.649.363.aaaa +1.425.868.aabb

WARNING: Fewer than 3 people found for Present list!


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 02 Mar 2011
Guessing minutes URL: [59]http://www.w3.org/2011/03/02-svg-minutes.html
People with action items: cameron doug erik jonathan patrick

      [59] http://www.w3.org/2011/03/02-svg-minutes.html

WARNING: Possible internal error: join/leave lines remaining:
         <scribe> ... One of the guys that really understands it has joi
ned this working group now and he's interested in reworking it



WARNING: Possible internal error: join/leave lines remaining:
         <scribe> ... One of the guys that really understands it has joi
ned this working group now and he's interested in reworking it



    End of [60]scribe.perl diagnostic output]

      [60] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm



-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Thursday, 3 March 2011 04:48:23 UTC