W3C home > Mailing lists > Public > www-svg@w3.org > January 2012

minutes, day 2 of SVG WG Sydney 2012 F2F

From: Cameron McCormack <cam@mcc.id.au>
Date: Fri, 13 Jan 2012 17:44:38 +1100
Message-ID: <4F0FD2D6.80104@mcc.id.au>
To: SVG public list <www-svg@w3.org>
http://www.w3.org/2012/01/11-svg-minutes.html

and below as text:

    [1]W3C

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

                                - DRAFT -

                          Sydney 2012 F2F day 2

11 Jan 2012

    See also: [2]IRC log

       [2] http://www.w3.org/2012/01/11-svg-irc

Attendees

    Present
           [IPcaller], Patrick

    Regrets
    Chair
           Cameron

    Scribe
           Cyril

Contents

      * [3]Topics
          1. [4]Web Animations
          2. [5]continuing Brian's animation topic
          3. [6]CSS animations targetting SVG attributes
          4. [7]Matrix API
          5. [8]Compositing
          6. [9]Web Animations
      * [10]Summary of Action Items
      _________________________________________________________

    <patrickdengler_> i do not have skyp.. hmm

    <heycam> patrickdengler_, we'll set up the zakim bridge

    <heycam> patrickdengler_, and get cyril to call in to it from here

    <vhardy> ScribeNick: vhardy

Web Animations

    [11]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2012/Agenda/An
    imations/WebAnimations

      [11] 
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2012/Agenda/Animations/WebAnimations

    <patrickdengler_> i'll dial in in about 35-45 minutes

    <heycam> patrickdengler_, is it ok if we begin on brian's topic and
    you come in half way through?

    <patrickdengler_> please begin brian's topic without me of course

    [12]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2012/Agenda/An
    imations/WebAnimations

      [12] 
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2012/Agenda/Animations/WebAnimations

    brian: this came out of the Seattle F2F to look at the features that
    are in SVG animations and not in CSS animations and then prioritize
    them according to usefulness.
    ... I wrote a long document.
    ... the first part is in response to the action, about features.
    This is input to the FX task force.
    ... I have written it for CSS animations people who do not know
    SMIL.
    ... I start by listing the differences. Then I created a few use
    cases. They may not be sufficient, I would appreciate additional use
    cases.
    ... then, I have attempted to prioritize.
    ... finally, this is what I would like to talk about, is the
    proposal for an element syntax that is a middle ground between CSS
    animations and SMIL animations. I would like to discuss the concept
    and see if there is support.

    chris: how does this differ from what Patrick is proposing?

    brian: Patrick is proposing to extend the reach of CSS animations in
    SVG so that you can animation more attributes by making them
    presentation attributes and animatable by CSS
    animations/transitions. My proposal looks at adding missing features
    in CSS Animations/Transitions, such as timing and synchronization.
    ... Going through what I have written down, here is what is missing
    from CSS animations.
    ... Timing. One major difference is that SVG animations have an
    absolute reference whereas CSS animations start on document load or
    at the time there is a property match.

    dean: yes, this is pretty imprecise in CSS. The actual time is the
    first time it renders, and CSS does not specify when that time would
    be precisely. This means forcing a style resolution. There is no
    real way to kick start the animation precisely.

    chris: is there a way to resolve this?

    dean: implementations end up doing the same thing and it resolves
    ok. Things are similar enought that people do not notice.

    <TabAtkins> As long as you're not trying to chain animations, yes,
    it's "good enough" right now.

    <TabAtkins> Being able to specifically relate animations to a
    timeline and/or chain animations together is something I feel is
    important to eventually support.

    shane: because the aniamtions are resolved on style resolution and
    style resolutions happen at different times, the user may get
    offsets between animations starts that he/she does not want and
    cannot control.

    dean: the current behavior is kind of ok, but we need something more
    precise.

    shane: I have a question about the SVG timing model. Can you sync.
    up two animations?

    (several): yes.

    (several): explain time conditions in SMIL, such as <animate
    begin="button.click" ..> and <animate begin="myFirstAnim.begin+2s"
    ... />

    brian: in point T1b), there is a description of the features
    available in SMIL.

    <cyril> zakim what is the code

    brian: getCurrentTime and then call beginElement, you will get the
    same time. This could be better specified.

    dean: In WebKit, for animations, we don't update/apply different
    times to the animation in the same script context.
    ... if you add several animations, they appear to start at exactly
    the same time.
    ... CSS does not specify when the animation starts between the time
    the style is set and when it really kicks in (at style resolution or
    first rendering).

    heycam: in SVG animation, you can specify an absolute time. In CSS
    animations, you can only specify somethign to start relative to the
    current time.

    brian: yes, that is correct.
    ... correct sync. with events is possible in SMIL animation.

    <heycam> (where by absolute time I mean an absolute time within the
    document timeline, not a wallclock time)

    shane: if we modified CSS animations to better define the time
    animations start, would that be desirable?

    dean: yes.

    <ed> Meeting: SVG WG Sydney 2012 F2F day 2

    dean: I think brian will go on to explain how an absolute timeline
    could work.
    ... I think that is ok. There should be a way to start at an
    absolute time.

    <TabAtkins> Sage.

    brian: Below T1 c), I propose ways to have a proper timing, like
    defining a time container in HTML. We can use inspiration from SVG
    Tiny.

    heycam: we already want a unified notion of time line for
    requestAnimationFrame and performance APIs, so we should also use a
    unified notion for CSS animations and SMIL animations.

    cyril: why did not CSS animation use a time container to begin with?

    shane: because it was defined to start at 'style resolve time'.

    brian: my proposal addresses these issues with proposals.
    ... I propose to consider the timelneBegin, as we have in SVG
    animation.
    ... I have a few suggestions to introduce the same in CSS
    animations.

    cyril: this is something we cannot decide here, right?

    brian: yes, this is input to the FX task force, an ACTION I had from
    the Seattle F2F.

    <TabAtkins> CSS Animations were defined in a very limited and weak
    way at first. They simply run as long as the property applies,
    starting "when the property starts to apply" and stopping when it
    stops.

    brian: we are not trying to decide here now. I am looking for input.

    <TabAtkins> By the way, Brian, excellent doc. Lots of food for
    thought.

    brian: moving on to T2.
    ... in SVG animations, you can schedule multiple intervals. There is
    only one in CSS animations.

    heycam: CSS animations only support something like 'style resolution
    time' or 'style resolution time + offset'.

    brian: yes, that is true, but you cannot control playing the
    animation multiple times declaratively.
    ... if introduce that feature, we need to decide how overlaps of the
    same animation are handled. SVG animations specify how to handle
    that type of situation.

    <TabAtkins> From pure CSS, we'd have to add another at-rule or
    something that defined an animation separately, so we could tell it
    to start based on various things.

    heycam: in SVG animations, you can have indefinite values in the
    list, and then you can start the animation with a script call
    (beginElement).

    <TabAtkins> Alternately, create a decent JS API for constructing
    Animation objects.

    <TabAtkins> Or rely on the increasing merging of SVG into the other
    languages and have an element in SVG for it.

    heycam: the CSS equivalent is to manipulate the style to set the
    animation-name to none and then set it again.

    brian: going on to T3, aborting animation. There in an end attribute
    in SVG animations.
    ... that is not available in CSS.

    <TabAtkins> Note: I do *not* think that extending the power of the
    'animation' property is the right direction here for almost any of
    this.

    <TabAtkins> 'animation' does a single simple thing and does it
    reasonbly well. It shoudl be considered a shortcut for applying
    animations while an element is in a particular state, not the
    canonical way to interact with animations.

    vhardy: you can abort an animation in CSS, but not declaratively,
    you need to manipulate the style.

    <TabAtkins> imo

    <TabAtkins> We should be considering animations as objects separate
    from the 'animation' property when thinking about how to address
    most of these.

    <TabAtkins> (Similarly, 'transition' does a single simple thing
    well.)

    <birtles> TabAtkins, ok that's good. The "proposals" aren't serious,
    just showing how these features relate to CSS Animations. Other
    proposals are very welcome.

    chris: Microsoft has expresssed that they do not want to implement
    SMIL animations. So if we want more features or address the
    problems, we need to add features to CSS Animations.

    <dino> i agree with Tab (mostly - I do think we can extend the
    animation property to solve some of the things in Brian's document
    in a simple manner)

    vhardy: may be if we can demonstrate that more features are needed
    and that adding them to CSS animations creates the same amount of
    work as implementing SMIL animations, Microsoft may reconsider their
    position?

    <TabAtkins> dino: Yeah, some of the things may be appropriate for
    extending 'animation' - this is a long list. ^_^

    vhardy: I also agree that having a common underlying model that
    different syntaxes / markups map to is the right architectural
    approach.

    <TabAtkins> vhardy: I still doubt that they'd like to implement two
    separate animation models. We'd like to remove SMIL from Chrome, too
    - our implemenation is shit and a big security hole.

    <TabAtkins> Fixing the security bugs is a "reimplement the whole
    thing"-level task.

    <dino> I do agree vehemently with the goal to not make the CSS
    syntax for animations much more complex than it currently is. I'd
    rather go without features in the CSS syntax than make things
    confusing. I'd prefer a JS API. This goes quadruple for transitions.

    chris: people do not want to have SVG animation elements because
    they want styling and animations seperate.
    ... the animations could be started from a stylesheet but pointing
    to a resource where the animations are defined.

    vhardy: I think that animations are sometimes content sometimes
    styling. For example, if you do a cartoon, animations are the
    content. If applying to an HTML dialog, they are styling.
    ... also, I think that because there are issues with SMIL engines
    implementations, we should not conclude that the issue is
    necessarily with SMIL itself.
    ... there are a lot of good things in the SMIL model that I hope can
    be the underlying model for a common animation solution applying to
    CSS, Scripting (and obviously SMIL).

    heycam: I think the SMIL scripting APIs are limited.

    vhardy: yes, my point is that if we defined better scripting APIs
    for animations, we should leverage the same underlying model and use
    the SMIL timing model as much as possible.

    brian: I don't agree an API will solve everything. Sometimes, we
    need more APIs for animation, but I do not think that will be
    enough. I think declarative animations is needed. We need a way to
    do reasonably sophisticated animations declarative animations.

    chris: I agree.

    vhardy: I agree.

    cyril: we've had SVG animations for a long time, they are
    declarative, and no one is using it. Why are people using CSS
    animations more, specifically in authoring tools.

    chris: there is not much room for a tool for CSS in general, and in
    particular for CSS animations.
    ... I do not expect tools editing CSS animations in general?

    rik: why not? All the information is there?

    chris: I am talking about reading content that was not written by
    the tool?
    ... for CSS in general.

    cyril: I agree with brian in general. It is better to have a
    declarative solution for authoring tools.

    brian: regarding the adoption, CSS animations apply to HTML and SVG
    animations to SVG. There is much more HTML than SVG, so that
    explains the difference in adoption.

    <patrickdengler_> There is always this agrugment between declarative
    and code. Historically, code in browsers meant x-scripting issues.
    In non-HTML contexts, declarative vs. code has become a bit of a
    redherring. Yes, tools and tool declarative syntax better, but the
    harder you push declarative support, the harder it is to understand
    the concepts, and thus the harder it is to tool them.

    <patrickdengler_> Does that make sense?

    vhardy: I think one factor too is that CSS animations, at least
    initially, have been used for UI effects that do not require as many
    animations and synchronization as you would need for complex
    cartoons for example. For the types of animations enabled by SMIL,
    tools are needed and there have been a lack of tools so far.

    <patrickdengler_> and untoolable

    <patrickdengler_> declarative is still code :)

    tab: I agree with Patrick.

    heycam: I think the declarative v.s. scripting is a bit off-topic.

    brian: the argument put forward is that all we need is a very
    elementary CSS animation and then a scripting API. I disagree with
    that position.

    vhardy: yes, I agree.

    brian: yes, it is not just about tool support. Security is one of
    the major issues, probably the main compelling reason. You can use
    animations where you cannot use scripting.
    ... back to T4 on synchronizing animations. That is in SVG
    animations and not in CSS.

    <patrickdengler_> I respect Brian's well done analysis. My position
    is that if you increase the feature set of CSS Animations, and back
    it with a richer API, that this is a better balance long term.
    That''s all.

    brian: there is a proposal to how to add synchronization to CSS
    animations, it is rough.
    ... it is a big feature.
    ... T5. Seeking the document timeline.
    ... that would be useful in CSS animations as well.

    dean: yes, this is useful. CSS animations does not really talk about
    time containers. So theoritically, each animation is in its own
    timeline.

    brian: T1 may be a pre-requisite for this feature.

    chris: having unsynchronized timelines is not useful, because it is
    common to need to sync. animations.

    cyril: do implementations implement time seeks?

    brian, ed: yes.

    cyril: Is it well specified?

    brian: yes, it is decent.

    cyril: do we have tests in the test suite for those?

    ed: yes.

    brian: T6, ability to pause the timeline.
    ... T7: repeating by duration instead of duration count.
    ... this might even be more important with time containers.

    dean: this is not currently an issue because you always know the
    duration of children.

    brian: it is a convenience, and you can often calculate it and use
    repeatCount.

    dean: what is an example of why you would use repeatDuration?

    brian: when you want to sync. on the duration of other animations
    and not want to compute how many hundreds of iterations that makes
    in the other aniamtions you are trying to limit in time.
    ... T8, triggering animations from arbitrary events.

    cyril: there is a difference between using the begin event and the
    begin sync. arc.

    <cyril> <animate begin=a.begin> is different from <animate
    begin=a.beginEvent>

    brian: there are differences, the most important one is negative
    offsets. With sync. base timing, the time will be resolved, but with
    the event base, the animation will only start after the event has
    fired.
    ... there are also differences with seeking.
    ... so this is the argument for keeping sync. based timing.

    <heycam> [brian shows a demo]

    brian: showing a demo of a video and an animation sync. up with the
    video.

    <cyril> [13]http://brian.sol1.net/svg/demo/video.html

      [13] http://brian.sol1.net/svg/demo/video.html

    <birtles> <animate attributeName="stroke-dashoffset" from="9px"
    to="0px"

    <birtles> dur="1s" repeatCount="indefinite" fill="freeze"

    <birtles> begin="video.playing" end="video.pause; video.ended"/>

    dean: I most cases, I have found writing content to do something
    like this, you want to triger the event with a conditional
    expression.
    ... e.g., you click and some other state exists.

    vhardy: when coupled with custom events, this provide a pretty
    elegant solution, because you can triger animations on application
    events.

    <patrickdengler_> sorry, what?

    BREAK for 15mn then continue on Brian's topic.

    <patrickdengler_> The only topic I have for CSS Animations is going
    to be: are we all good with this proposal :
    [14]http://lists.w3.org/Archives/Public/public-fx/2012JanMar/0003.ht
    ml

      [14] 
http://lists.w3.org/Archives/Public/public-fx/2012JanMar/0003.html

    <patrickdengler_> I've not heard any additional feedback beyond
    Dean's, which is incorporated, and I have otherwise heard support.
    If this is the case, I'd like a resolution to accept this, at which
    point I am happy to make the edits in the specification.

    <TabAtkins> Yes, I'm good.

    <patrickdengler_> If not, let's discuss.

    <patrickdengler_> I had hoped to have a prototype to run on webkit,
    firefox and Opera, but it only runs on IE so far. Once I have the
    prototype running on all browsers, I will put the code on some open
    source place so people could drop it in and make their sites
    backward compatible.

    <ChrisL> patrick, I sent some feedback on elevation and azimuth,did
    you see that?

    <patrickdengler_> I saw your feedback on elevation and azimuth. I
    believe that is included in the link. If I recall you noted that
    these could and should be deprecated in the CSS Aurul spec so we
    don't have to rename them. Is that correct?

    <ChrisL> yes

    <heycam> patrickdengler_, since we're not having an official FX
    meeting here, are we able to officially resolve that?

    <heycam> patrickdengler_, we can say whether we (SVG WG) is happy
    with it

    <patrickdengler_> THat's fine, let's start there though. Dean is
    good with it and perhaps he can shepard it over to CSS

    <heycam> ok

    <heycam> we will just wait a few more minutes for vincent to return

    <patrickdengler_> I am on the line

    <heycam> ScribeNick: heycam

continuing Brian's animation topic

    BB: first A1, animateMotion

    … that's not possible in CSS

    … seems to be quite useful

    … we've also already resolved to support a more general case of
    animation of pairs of values

    … that's an abstraction of animateMotion I guess

    … (these are animation value features not in CSS)

    … next, the ability to combine animation values with underlying
    animations, instead of replacing

    … I think Dean mentioned in Seattle that there's already been some
    proposal to add something like that

    … wasn't sure if that referred to this, or adding separate
    animations together

    CM: what's the difference between A2 and A3?

    BB: in SVG they're the same, since they both use the same concept of
    underlying animation values

    … A2 is just considering the base value of the attribute

    … A3 is an extension of that where you can have additive animations

    DJ: A3 is what has been requested for CSS Animations before

    BB: one other difference is that I believe CSS Animations takes a
    snapshot of the values when it begins animating

    … in SVG animations it's live

    … if the underlying value changes then the animation will reflect
    that change

    CL: does that mean if the script manipulates an already running
    animated animation property it doesn't have any effect until the
    animation ends?

    DJ: the only way you could see something happen is if the script
    manipulates the animation attributes

    … in CSS if you have an animation on an element, manipulating colour
    e.g., if you set the color on the style property of the element it's
    never going to change while the animation is running

    … since the animation always overrides it

    … if while the animation is running, you find the @keyframe and
    update the values there, the animation also doesn't change

    … you might expect to be able to change the duration while it's
    running, but the spec says that shouldn't work

    … which gets back to restarting animations, you have to remove and
    replace it

    … which is annoying

    BB: another point about A3 is that this is where the animation model
    comes in, which animation goes on top of which

    … some people are not keen on that model

    <dino> "As Anne van Karsten points out" - new nickname!!!

    … it might be worth reassessing how animations combine together

    … the last animation feature is combining animation with itself,
    that's accumulate="sum" in SVG

    DJ: how often is this used in practice?

    BB: I suspect not that often

    … but I don't really know

    CC: what is "SVG's endpoint exclusive timing model"?

    BB: that's where at t = 0, the animation effect is applied, but at t
    = 1 it is not applied

    … that's important when you accumulate

    … otherwise you'd have overlap

    … it's also significant when you have absolute time references

    … if you query the animation at that exact end point, the animation
    is not being applied so the unanimated value will be returned

    … now, a couple of other quick items

    … document structure -- SVG allows you to interleave animation
    content with the stuff you're animating

    … Anne pointed out that this is possible with CSS if you use <style
    scoped>

    … which noone supports yet

    … but will be possible

    … I think it's a little cumbersome, not totally convinced by it

    <TabAtkins> Chrome is nearly done supporting it.

    <TabAtkins> But I agree that it's cumbersome.

    … but it is technically possible to interleave CSS Animations with
    the content

    DJ: I would think if we want to add to this wiki document, we should
    a D2, timesheets

    … not interleaving, but still...

    BB: I'm just looking at what's in SVG but not in CSS

    … it is sometimes useful to separate out the animations from the
    content though

    … now features that don't exist in SVG Animations

    … I think if we're going to keep SVG animations, then we really
    should have time containers

    … they give so much utility, the use cases I'm going to present
    would be easier with time containers

    CL: I agree, we were in favour originally

    CC: in the 1.2T timeframe we agreed to time containers, but not
    nested ones

    BB: I'm wanting nested ones

    CC: you don't want the sync attributes though?

    BB: no, just the nested time container elements

    … this is one feature that I think is particularly well suited to
    element syntax, and not so much the CSS syntax

    DJ: my hestitation is that it starts putting the animation structure
    into the document, whereas at the moment where animations are just
    children of the elemnets you can think of them like decorations to
    the content

    … what this means is what we put into SVG now leaks into HTML

    <TabAtkins> Agreed on this being well-suited to element syntax
    rather than CSS at-rules. at-rules aren't great for nested
    structures.

    … that community less likely wants animation as content

    BB: there is a lot of discussion around animation in HTML markup

    … I think we want to support animation as content

    DJ: actually this doesn't need to be SVG, this could equally be done
    in HTML

    … (animation content)

    VH: I believe SMIL originally took a lot from Real Networks

    … they were doing a lot of education content, mixing audio, video,
    overlays, etc.

    … so they had a lot of sync work to do

    CL: most of that was streaming content as well

    VH: so they had a lot of real use cases for doing rich timed
    multimedia content, the content itself is timed by nature

    … it's important to capture the time aspect of the content

    CL: one aspect of that would be audio and video, coming from
    separate sources, and you want the video to sync with the audio

    … you care about audio jitter, but not video so much

    <patrickdengler_> Side note: I agree, that if you are going to talk
    about introducing elements to support animation or new animation
    functionality, you must do it in context of HTML, not just SVG.

    … but in other cases you might care about audio being synced to
    video

    DJ: if it's content, you're forcing the author to use it that way.
    if it's stylistic, you can do it either way.

    CL: say if you have some audio/video, some people want audio in some
    other language, or some people want subtitles

    … we've traditionally thought of those choices as stylistic, but
    it's a slipper slope

    … this hard wall of style vs content is more nuanced than is often
    presented

    ack

    DS: brian you said that time containers are better suited to element
    syntax, why is that?

    BB: because the proposal I've put forward is arbitrary nesting of
    time containers, including seq

    … in that case obviosuly it's a hierarchical arrangement

    … I think as Tab mentioned too, that's harder to do with @at rules

    … with an element syntax it's fundamnetally hierarchical

    DS: couldn't you have a CSS rule apply to an already predefined
    container, like a <g> or a <div>?

    BB: yes but then you'd need a rule for each <g> underneath that, and
    you'd need to match up the rules with each of the nested <g>s

    … I think that would be cumbersome to deal with

    DS: you have to define it either way

    … if it's part of the hierarchy, or in a CSS rule applying to a <g>,
    it's only where you define it

    … if you should ever want to change the nature of a time container,
    or a <g> that has a style rule applied to it, if you want to turn on
    or off a particular thing, you could do that …

    DJ: you could have an excl element, where the author wants it to be
    exclusive, different audio tracks for example

    BB: I think perhaps we don't need to solve this right now

    … I'm uncomfortable with the idea of mixing style in that way, where
    hierarchy is defined in content, but the meaning of that hierarchy
    is altered by style somewhere else

    DJ: it doesn't need to live somewhere else

    … you can put style attributes, or in SVG presentation attribtues

    BB: if it's a presnetation attribute it's not that different from
    what I'm suggesting

    … I suggested a grouping element, but it could be just an attribute
    on existing elements

    CC: you could use SMIL3 time sheets

    DJ: you're right we don't need to solve this now

    … but it's an important feature to solve

    BB: even if we use CSS rules, we're still relying on element syntax
    to provide some of the structure

    <shepazu> that's fine, I don't need to press the point

    DJ: should the element structure also provide new behaviour, in
    which case you would want to introduce new elements

    BB: or attributes
    ... I have a few use cases which I've already mentioned, not
    exhaustive by any means

    … first is not particularly exciting -- this button

    VH: just one comment before the use cases

    … I think there's also the ability to target multiple elements,
    mulitple properties, is not in SVG animations

    … but we should support that

    BB: there's a lot of stuff that doesn't exist in SVG Animations

    … this was just a more detailed version of what I proposed for
    Seattle

    VH: can you point to the Seattle document from this one?

    CL: I think the multiple targetting is missing and something we
    could fix

    … dean and others have suggested using CSS selectors to do this

    … but the target of the animation is a set of nodes

    <scribe> ACTION: Brian to link to the Seattle animation document
    from the Manly one [recorded in
    [15]http://www.w3.org/2012/01/11-svg-minutes.html#action01]

    <trackbot> Created ACTION-3201 - Link to the Seattle animation
    document from the Manly one [on Brian Birtles - due 2012-01-19].

    BB: let's go through the use cases quickly

    … this button example was made to emulate a Flash button as a
    challenge

    … in order to do that, I've listed the features of SVG animations
    that were useful

    … multiple intervals, declaratively aborting animations,
    synchorising animations, triggering from events

    … time containers would have made this example much easier

    … this one, why not do it with script? might be a fair call for this
    example

    … generally with UI widgets it would be nice not to use script for
    the hover interactions etc.

    … next use case is more complex, a WIP

    … this is something we're doing for an event in a couple of weeks in
    Tokyo

    … there's an animation group that do workshops

    … they give everyone tablets where people create frame based
    animations

    [brian shows animation webapp example]

    … it's a collaborative project where the animations are uploaded and
    then combined into a display

    CL: can you publish this?

    BB: it's not quite ready, after the event in a couple of weeks

    … the features this example uses:

    … absolute time references, to insert the animations

    … synchronising the frames together, the ones you draw yourself

    … repeatDur

    … motion on a path

    … and combining with an udnerlying value

    … time contaienrs again would be useful, for the frame-by-frame
    animation, put them all in a <seq> container

    … one interesting thing with this, being declarative is an advantage

    … (though we are using script as well)

    … we'd like to be able to email peoples' characters to them, as a
    souvenir

    … can't run script in a mail client

    … when we embed subanimations in a master animatino, that's using an
    <image> element, and you can't run script in there

    … finally, example 3

    … an in progress animation tool for cutout animations

    [brian demos moving little parts of Foxkeh arround]

    CC: like Terry Gilliam's animations

    BB: this uses setCurrentTime, getAnimVal, etc.

    CL: it's a classic cell frame animation kind of thing

    <ChrisL> Classic cell-frame animation

    BB: so now I have a prioritisation of animation features based on
    these three use cases

    … a tentative prioritisation

    … this is my assessment of the bigger items to handle

    … these are the features in SVG animations not in CSS animation that
    we could bring over, prioritised

    CL: synchornising multiple video and audio streams from different
    sources is a different use case, but it uses the same features as
    these other examples do

    CC: no, you need the runtime sync attributes, syncBehavior,
    syncTolerance

    … they're different

    … time containers are containers that have a clock associated, they
    can be nested or not

    … and they can be of different type, par vs seq for example

    … then there's how does the clock behave when it drifts, they're the
    sync attributes

    … in 1.2T we have time containers, there can be multiple timelines

    CL: and they're implicit <par> containers?

    CC: and we have the sync attributes

    CM: should we be bringing all these features over from your list?

    BB: not sure, motion on a path and time containers for example might
    be hard to realise in CSS syntax

    DJ: we get a lot of requests for motion on a path

    … I agree with your suggestion, it's almost like a special case of
    transform animations

    … I don't know how to represent that, though

    … don't like extending animation syntax just to do motion on a path

    BB: this is just input for the FX taskforce

    … it needs further discussion

    … but things towards the top of the prioritisation list are probably
    more useful than those towards the bottom

    <patrickdengler_> I am

    <patrickdengler_> Is it time for my topic :)

    CM: I wonder if Patrick has any views on the set of features Brian
    has identified

    … and whether all or some should be brought across to CSS

    <patrickdengler_> I am by far no expert in animation.

    … it's probably not something we can decide right now though

    … but would like to hear his views

    <patrickdengler_> I love the idea of enhancing animations, but not
    to the extent where it overloads the syntax such that is unusable
    (opinion)

    CC: I want to know if there's any impact on our SVG2 requrirements
    decisions

    <patrickdengler_> Any impact of the proposal? no

    <scribe> ACTION: Brian to prepare before and after examples of using
    time containers in SVG animation [recorded in
    [16]http://www.w3.org/2012/01/11-svg-minutes.html#action02]

    <trackbot> Created ACTION-3202 - Prepare before and after examples
    of using time containers in SVG animation [on Brian Birtles - due
    2012-01-19].

    <patrickdengler_> Woot!

CSS animations targetting SVG attributes

    <patrickdengler_> I just want to see if we can get a resolution on
    the proposal I sent out

    <patrickdengler_> It's very basic and orthogonal to all of these
    other discussions.

    patrickdengler_, got a link? is it this?
    [17]http://www.w3.org/mid/D7C8ABF3132F9D439385C55C1955D82DE3399C@TK5
    EX14MBXC294.redmond.corp.microsoft.com

      [17] 
http://www.w3.org/mid/D7C8ABF3132F9D439385C55C1955D82DE3399C@TK5EX14MBXC294.redmond.corp.microsoft.com

    <patrickdengler_> It is one of the three options we discussed for
    moving CSS animations on top of a select few, targetted attributes

    <vhardy>
    [18]http://lists.w3.org/Archives/Public/public-fx/2011OctDec/0168.ht
    ml

      [18] 
http://lists.w3.org/Archives/Public/public-fx/2011OctDec/0168.html

    patrickdengler_, as there were a few options, can you briefly
    summarise which one this was? i.e. what set of attributes it targets
    and how it does it?

    <patrickdengler_> The last few open issues that I knew of were
    semantic and type collision resolutoin wasn't acceptable and I
    agreed

    <patrickdengler_> THe set of attributes are in the link above

    <patrickdengler_> Only 4 had collisions.

    <patrickdengler_> azimuth and elevation, which were both parts of a
    CSS Aurul specification, that ChrisL said we could deprecate in that
    specificaion (correct?)

    <patrickdengler_> transform, which dean has started a nice proposal
    through implementation, and which has other implicatoins outside of
    the scope of this proposal

    patrickdengler_, I'm having trouble refreshing my memory -- was this
    the proposal to upgrade attributes to properties, with the same
    names as the svg attributes?

    <patrickdengler_> Yes.

    CL: I object to upgrading attributes to properties

    … I think instead we should "treat" these attributes as if they were
    properties

    … for the sake of CSS animation

    … that's a big difference

    … if we make randomly every single attribtue in SVG (practically) it
    means they apply to all elements

    … and things like x and y which don't make sense on most of them,
    it's a bad idea, leads to a lot of bloat

    <patrickdengler_> wait

    … whereas the same proposal, but with a slight wording change

    … taking a mechanism that was originally designed to work only with
    properties, and let it treat SVG attributes as if they were
    properites for the sake of animation

    <patrickdengler_> this is not right

    <patrickdengler_> Does font-size apply to circle?

    <patrickdengler_> we have properties that don't apply to elements.

    DJ: so you wouldn't be able to style these attributes with CSS
    unless you were animating

    <patrickdengler_> What does property bloat mean? If you are thinking
    implementation that argument doesn't apply.

    … and you wouldn't be able to use Transitions on them

    <ChrisL> would mean that the attributes are *treated as* properties
    for the sake of CSS animation

    <ChrisL> no real impact on the proposal itself, just a change in
    terminology

    VH: I understand Chris' point, but I htink from an authoring point
    it would be confusing to target them from animations but not be able
    to put them in a normal style rule

    … if you can put x in one place but not in others

    <patrickdengler_> They have to be properties

    … that would be confusing

    CL: so yes it has differences on these other side effects

    … not transitioning is a negative side affect, I agree

    DJ: I think transitioning is important

    … transitioning a circle radius would be very useful

    <patrickdengler_> Transitioning is key and part of the proposal

    CL: the CSS WG would not be amenable to adding many properties

    <patrickdengler_> You cannot separate them. The proposal is to make
    them properties.

    VH: this needs to be taken to the FX, yes?

    … can we bring it to the TF, if we all kind of like the idea, but
    there are concerns about adding that many properties, and ask for
    their input?

    <patrickdengler_> This has been taken to the FX group; I have shared
    it on those threads. Everyone has given feedback and agreed
    (including ChrisL). What other magic do I need to do?

    … we can bring up Chris' issue in a real FX setting

    CL: I just think this had a lot of downsides and there's another way
    to do it

    … we need to weight up the pros and cons of this approach

    CL: no, I didn't say I agreed to the whole thing, just the specific
    point that was asked about

    … I'm not objecting here

    … I'm just saying we should consider another way forward

    VH: to answer patrick, for a decision we need to make that in an FX
    setting

    … not that it hasn't already been brought up there

    CM: I think we should get our SVG's view of it

    … to make half of that decision

    <patrickdengler_> I dropped off hang on.

    <vhardy> VH: I agree

    <patrickdengler_> I cannot get back on the line.

    <patrickdengler_> I am totally lost on process here.

    <patrickdengler_> The FX group has already sent all of the feedback;
    the FX group is all present here correct?

    patrickdengler_, no I don't think all of the FX group is here

    VH: david baron isn't here

    <patrickdengler_> Can you set up another conf?

    <patrickdengler_> #

    … I think he will still have issues with this

    <TabAtkins> It is slightly troubling from a CSS perspective to add a
    bunch of properties that apply to only a single/few elements each.
    Most CSS properties are relatively widely applicable.

    … Tab also

    patrickdengler_, yes

    PD: this discussion has been going on for over a year

    … hundreds of emails

    … at every meeting I've written up proposals, presentations

    CL: I didn't say it was no good

    … I said the vast majority was fine, just concerned about the side
    effects of it

    … I proposed something that mitigated those side effects

    … I just want to talk about that

    PD: we discussed property growth last year, and we've addressed that

    … we definitely need transitions to work

    CM: I don't get the sense that anybody wants CSS animations not to
    work on SVG attributes

    <TabAtkins> I'm pretty happy with the actual property set we've done
    so far.

    <ed> TabAtkins: what property set do you mean? the one that's in CSS
    transitions?

    <TabAtkins> I mean the one that was proposed by Patrick. It's only a
    handful of properties. Once the few collisions are handled better,
    which has gotten good suggestions, I'm pretty happy.

    [discussion of process on how to move forward]

    DJ: patrick has done a lot of work, getting private and public
    feedback

    VH: there are two things, one appreciates all the work you have done

    … the point about making the decision in the FX setting, if we make
    a resolution today it's just a technicality

    … a final recorded decision needs to happen in the FX group

    CM: we should go through each of these proposed resolutions

    CC: I feel like if we agree to this proposal, or even say Brian's
    proposal, it's the end for SVG markup for animation

    … that's how I feel

    … people will use CSS Animations to target animations

    … it's like we're deprecating SVG animation elements

    DJ: not really, we're giving people a better way to animate content
    in some cases

    … I think you're implying that because we're going in this
    direction, it's deprecating SMIL

    … I don't think that's the case

    BB: just extending the reach of CSS animations doesn't jeopardise
    the usefulness of SMIL

    CC: we'll just end up with two tools for the same thing

    DJ: we should have discussed this a year ago

    … we've been discussing how to do this, not whether it should be
    done

    … in general, most people want to be able to do CSS transitions and
    possibly animations on SVG content

    BB: and you already can for style properties

    DJ: yes, and we have a specially worded spec so you can do it for
    transforms now

    … but even with that, there's a bunch of graphical parts of SVG
    that's not exposed

    <TabAtkins> I think we shouldn't worry about hurting SMIL's
    feelings.

    VH: for the sake of progress, we have 20mins here, and we have
    multiple issues, I propose if somebody has an issue with one of
    these resolutions we do that now

    … and if not, we assume it's ok

    [mention issue #1]

    CL: I agree with that resolution, we should keep the existing names

    VH: for width, you could have a width property that applies to
    <rect> and to <div>

    CL: that's a separate problem

    … width/height in SVG are not the same as those in CSS

    … they mean different things

    … that's the reason why SMIL had attributeType

    DJ: I don't think there's much chance someone would write a
    stylesheet that sets width on <rect> and root <svg>

    CM: it doesn't inherit

    <patrickdengler_> (I can no longer hear on the phone)

    issue #2

    CM: we have already resolved to fix this for SVG2

    … so this issue isn't a problem

    CL: yes, we've already decided to unify the syntax between
    presentation attribetus and properties

    issue #3

    [discussing style vs content briefly]

    CL: if implementors think promoting to properties is not a problem,
    then it's fine

    … I don't have a problem with promoting to properties if
    implementors are happy with it

    CC: when I implemented SVG, there is already a burden with style
    resolution and propagating values down the tree

    … it's not a big burden

    … I'm just wondering how much worse this will make it

    ED: I am wondering too, we'll just have to implement and see

    CL: I'm guessing most implementors do this with a big table with all
    the values
    ... these will most (all?) be non-inherited properties

    <patrickdengler_> non-nherited

    … in terms of propagation through the tree, the scope of impact is
    limited

    CC: unless you set "inherit"

    CL: yes you can always put "inherit"

    CC: so all these properties would allow "inherit"

    CM: and "initial"

    … but I don't think that's a problem

    DJ: we converted transform to a property

    … and that property already existed

    <patrickdengler_> tada :)

    … so we can't use that as an indication for how much impact there is

    … the webkit prefixed transform property applies to SVG elements

    <cyril> how many properties are we talking about?

    CM: so there's 47 properties in the proposal table

    CL: oh so no it's not all animatable attributes?

    CC: no, just a limited set

    ok so there's no implementors in here saying they definitely have a
    problem with promotion, in terms of performance impact

    we can move on

    issue #4

    <patrickdengler_> You just answered #4 I think

    well we need to be happy with that particular set

    patrickdengler_, what is the actual set there, as a summary?

    <patrickdengler_> The summary is in the proposal

    <patrickdengler_> It is scenario driven

    VH: it's a good set of properties

    <ed> I would like to see the excluded property set

    <patrickdengler_> It is based upon the use cases I presented.

    <patrickdengler_> I can produce that, but not tonight.

    CM: I don't think the particular set matters right now

    <patrickdengler_> I am not against promoting others, I was just
    trying to restrict based upon use case and to avoid collsions

    CL: I think CSS people will complain about overgeneric names like z,
    but we already have overgeneric names like "color"

    <ed> patrickdengler_: that's fine, but I think it would be good to
    include that set too, for completeness

    CM: so I'm happy that patrick has come up with a reasonable set of
    properties here

    issue #5

    CC: what if I put 'x' on a <g>, and then I have a <text> underneath
    it

    … what's the rule?

    <patrickdengler_> X doesn't apply to g does it?

    sorry I meant to type <svg>

    CM: I would prefer not using different names in case of conflicts

    … just define what happens if you have <rect style="x: 10px 20px">

    … that's better than coming up with different names, which is
    something new for authors to learn

    patrickdengler_, I'm having trouble reading your proposed resolution
    here, what is it?

    <patrickdengler_> For this case, it is just as was suggested. Define
    what happens if you have <rect style=

    <patrickdengler_> "x:10px 20px"; that should be a css rule already
    no?

    <patrickdengler_> (i.e. what if I put left:20px 40px

    <ChrisL> patrick, whose comment is the capitals, red text in your
    document

    no because you need to have the single x property defintion take the
    union of all possible values

    <patrickdengler_> I think the comments in red (if you are looking at
    my last sent one) are Dean's

    so anyway, I think we don't get this for free from CSS, but we just
    need explicit wording to say what happens when you do <rect
    style="x: 10px 20px">, which is fine

    <patrickdengler_> I don't konw what you mean by having a single x
    property take the union of all possible values. Sorry, not an
    expert, just trying to solve a problem :)

    CL: I think that's the right approach

    patrickdengler_, I don't think you can have two separate property
    definitions for when they apply on different elements

    patrickdengler_, because properties are universal

    patrickdengler_, but I think it's not a problem, and everyone here
    agrees

    issue #6

    CL: so this is only in the case of conflict with existing
    properties?

    CM: in practice the only problem with font-size and the font
    shorthand?

    CL: yes

    <patrickdengler_> azimuth and elevation as well but CL and I
    dicussed that one (if he can elaborate)

    CM: so what about width and height? we allow unitless values there?

    patrickdengler_, would we allow <rect style="x: 10">?

    <patrickdengler_> I think this problem already exists (?) in SVG,
    and unless there is a unit type, it isn't valid

    patrickdengler_, I'm not sure from reading the proposed resolution

    <patrickdengler_> I wouldn't change CSS here; I would force SVG for
    lengths to require unit types.

    patrickdengler_, right that is currently the case

    patrickdengler_, but not in presentation attributes?

    <patrickdengler_> (but not for floats)

    <patrickdengler_> (unless css introduces this)

    VH: I think it might be confusing for authors not to allow unitless
    values for these promoted attributes

    <patrickdengler_> I think they'll figure it out

    CM: this confusion already exists though
    ... so I don't think it matters for acceptance of this proposal

    everyone here happy

    issue #7

    <patrickdengler_> Issue #7 I resolved slightly differently, and it
    now falls into issue #5 category I think

    I don't think this is right

    <patrickdengler_> (it should be at the top)

    yes, so because of issue #5 we have a single universal property
    definition

    in that example you quote, the second rule will always win

    and then we just define how it behaves if applied to an element that
    only really wants a single value

    patrickdengler_, that make sense?

    <patrickdengler_> Yes

    issue #8

    we are ok with the particular set

    RESOLUTION: The SVG WG is happy with Patrick's property promotion
    proposal for targetting SVG attributes with CSS animation

    <patrickdengler_> I LVE YOU ALL

    CM: we should mail the fx list to say that the SVG WG is happy with
    the proposal

    <patrickdengler_> That would be great!!!!

    … schedule an FX call in a couple of weeks (since some of us a
    travelling)

    … so that we can get their agreement too

    … hopefully that mail about our acceptance of the proposal
    stimulates concerns to be brought forward from the CSS folks

    patrickdengler_, we might break for lunch now then

    <scribe> ACTION: Erik to mail FX list with our acceptance of
    property proposal and to schedule a call [recorded in
    [19]http://www.w3.org/2012/01/11-svg-minutes.html#action03]

    <trackbot> Created ACTION-3203 - Mail FX list with our acceptance of
    property proposal and to schedule a call [on Erik Dahlström - due
    2012-01-19].

    -- break for lunch, 1hr --

    <shans> ChrisL: [20]http://code.google.com/p/experimental-css/

      [20] http://code.google.com/p/experimental-css/

    <cyril> scribe: Cyril

    <scribe> ScribeNick: cyril

Matrix API

    <dino>
    [21]http://lists.w3.org/Archives/Public/public-fx/2012JanMar/0007.ht
    ml

      [21] 
http://lists.w3.org/Archives/Public/public-fx/2012JanMar/0007.html

    DJ: the idea is that when you're doing a lot of txf maths in matrix,
    the overhead of writing your own matrix class
    ... is annoying
    ... 1) because of the performance
    ... 2) because the API is immutable you create a lot of objects that
    you'll throw away
    ... 3) converting to and from a CSS transform because you go through
    the string API
    ... this is a proposal for a 4x4 matrix API
    ... I removed skew
    ... i hate skew and there are other ways to do skew
    ... there are 4 constructors
    ... Float32Array close to the WebGL
    ... it's defined in the type array spec
    ... it could become a JavaScript type

    CM: in WebIDL you can't override if you've got 2 types and they are
    both array or sequences

    DJ: but that's not a problem

    CL: how do you do perspective ? you have to go to 3d (4x4)

    DJ: yes
    ... there should be a perspective function
    ... for rotation, scale and rotation functions, there is a mutable
    and immutable version

    CM: since it's multiplied by it should be inverse of

    DJ: rotate, rotateAxisAngle

    VH: shouldn't we have the angle value before the x,y,z value

    DJ: I'm not sure SVG takes degres

    BB: should there be an immutable version of leftMultiply

    DJ: because it's immutable and returning a new matrix, you can do it

    CL: I think it's worth adding a comment on that

    DJ: typically people won't use the immutable versions

    VH: there is no center in the rotations

    DJ: right, we should have that
    ... same for scale from origin
    ... then there are 3 conversion functions
    ... getting the float32array

    <heycam> dino, you should write "stringifier;" rather than
    "DOMString toString();"

    DJ: David and Robert made this comment, they want to add units
    ... because if you've zoomed the page,
    ... you don't know the units

    <dino> feedback from Simon Fraser: It's problematic to pretend that
    you can convert matrix() from getComputedStyle into a 4x4 unitless
    matrix, because you don't have any context that tells you how big a
    pixel is. This means that it breaks down if full-page zoom has been
    applied.

    CM: is the issue that in the actual property you can't put units ?

    DJ: this API is just about matrices but the problem is when you try
    to mix it with CSS TRansforms

    <ed> just a note, the SVGTiny12 uDOM has an SVGMatrix interface that
    has methods that mutate the object

    <ed> [22]http://www.w3.org/TR/SVGTiny12/svgudom.html#svg__SVGMatrix

      [22] http://www.w3.org/TR/SVGTiny12/svgudom.html#svg__SVGMatrix

    CM: an example is if you have scale(2px)scale(3em) and exposing that
    as a matrix with unitless values
    ... then it's going to work if you put that back to the same element

    because of the em computation

    VH: what's our goal here?
    ... are we collecting feedback
    ... or solving the issues

    DJ: I'm taking notes and will produce another version

    VH: maybe we should have a way to set the txf center instead of
    adding a parameter

    CC: but then it becomes stateful

    DJ: and it becomes a transformation class instead of matrix

    CM: is it going to be exposed when you get the transform property?

    DJ: this could be substituted to CSS Matrix or SVG Matrix
    ... it wouldnt be returned by the transform property but accepted by
    the setter and the same for other SVG properties
    ... people have requested a way to decompose it

    VH: does it return an array of matrix

    DJ: we'll have to define another class
    ... so that's why I left it out for the moment, like lookAt that
    needs a point/vector class
    ... lookAt is a different way to do rotation without angles

    CM: can you use the CSS animation to do that camera rotation?

    DJ: yes
    ... you would have to decompose into rotation yourself
    ... for an object rotating around another, it'll be possible but for
    translation at fixed velocity, it would be hard

    VH: you could nest it

    <shepazu> (how else can you do skew x/y? they aren't great, but the
    best way I know to make pseudo-3D shapes in SVG...)

    DJ: I've removed skew and I hope people are happy

    CL: the way to do skew is to go 3D

    RC: but people like pseudo 3d

    DJ: the only good use of skew is asymmetric diagrams

    s/asymmetric/isometric/

    VH: I don't have a good feeling about removing skew

    CC: it's possible with the matrix coefficient

    DJ: yes, I'm not giving the shorthand for that

    <heycam> shepazu, this is just the Matrix API -- you can still put
    skew as a transform item in the transform property

    VH: have you looked at the apis that provide skew or not ?

    <heycam> shepazu, (and of course it's always possible to set the
    components yourself; mind you I have no opinion on not having them)

    VH: if it's popular, I would keep it

    CL: no problem to changing to degrees?

    DJ: no

    VH: what is ortho?
    ... projection that is not perspective
    ... in GL you give the frustrum (near, far)
    ... in general, for GL use, people will port GL code and reuse it

    s/frustrum/frustum/

    scribe: in CSS we do have a perspective which is one coefficient in
    the matrix
    ... that's different from what most people do in GL

    RC: maybe we should build a graph of operations, under the hood

    DJ: that's interesting
    ... anyway, we're starting to implement that in WebKit

    BB: where would that be used ?

    DJ: WebGL code
    ... they get hit by 2 things: matrix and garbage collection

    BB: what's the relation with SVG?

    DJ: it's more an FX item
    ... but maybe some SVG people would benefit from that (D3 ?)

    BB: SVG is 2d, what's the benefit of having a 3d

    DJ: maybe none, maybe there would be an overhead
    ... the biggest benefit is the mutability

    ED: SVGT1.2 has it already

    <ed> [23]http://www.w3.org/TR/SVGTiny12/svgudom.html#svg__SVGMatrix

      [23] http://www.w3.org/TR/SVGTiny12/svgudom.html#svg__SVGMatrix

    CM: is it part of the idea to move SVG and CSS matrix together

    DJ: it's not designed as a replacement
    ... in a perfect world, there should be a single matrix class
    ... but both are already quite different

    <krit> dino: which matrices differ, and how? SVGMatrix and
    CSSMatrix?

    <dino> krit: yes.

    <krit> dino: SVGMatrix has more functions, but I don't see where
    they would differ beside that

    <krit> dino: the additional functions don't influence the current
    matrix

    <dino> krit: i was just saying that they are different now. they
    have different api

    <krit> dino: I would rather like to make them more common

    <dino> krit: that's exactly what we're trying to do

    <krit> dino: SVGMatrix could inherit from CSSMatrix

    <krit> dino: ok, "... but both are already quite different" sounded
    like you want to sperate them more

    <krit> dino: so just a misunderstanding

    CM: this matrix class you would use it in all place where CSSMatrix
    is accepted

    DJ: not at the moment, it's more a standalone API at the moment

    CM: what's your view on other standalone classes (point...)

    DJ: it would be great if it would exist (dot product, cross product
    ...)

    CM: I'd like to see more general APIs

    DJ: but it's poluting the JavaScript namespace in browsers
    ... who are we to put things in the global namespace in Javascript
    ...

    <krit> soecification writer?

    DJ: that's why I called it Matrix4x4 instead of "Matrix"

    <dino> sure - i was just suggesting that we should be careful to add
    things into the global namespace

    <dino> without asking them

    <dino> krit, yes. I support merging SVGMatrix and CSSMatrix. I dont
    think Matrix4x4 is the right place to do that (maybe it is)

Compositing

    <cabanier> email:
    [24]http://lists.w3.org/Archives/Public/public-fx/2011OctDec/0150.ht
    ml

      [24] 
http://lists.w3.org/Archives/Public/public-fx/2011OctDec/0150.html

    <shepazu> we could talk to TC39 about adding Matrix to JS space…
    there are some who want to see tighter integration of JS with the
    Web usage and DOM (e.g. Alex Russel)

    <krit> dino: if you plan a common Matrix API, why not?

    RC: here are the mail of last months
    ... I'd like to split the spec into 2

    <dino> krit, i was simply worried that it would become a monster of
    3 apis :)

    RC: people agree that there will be 2 keywords
    ... 2 properties: alpha-comp and blending

    <krit> dino: I support your proposal

    <heycam> ScribeNick: heycam

    RC: blending does not do compositing, it takes the source image,
    calculates the background, then produces a new image

    … which is then composited on to the background

    … you don't composite first then blend

    CC: but the blending only applies to the regions where there are two
    inputs to work on

    DJ: no

    RC: the compositor figures it out for you

    … blending calculates an image

    CC: based on two values, right?

    DJ: based on the background and foreground

    … and they only exist in the area the compositing operations has a
    result

    DJ: the background always has a value

    CL: it might be transparent black, but it always has a value

    VH: are you thinking of examples like clear?

    RC: the background is calculated by taking all the …

    CC: if you take what's in the spec now, it uses four parameters

    <ChrisL> thread at
    [25]http://lists.w3.org/Archives/Public/public-fx/2011OctDec/thread.
    html#msg150

      [25] 
http://lists.w3.org/Archives/Public/public-fx/2011OctDec/thread.html#msg150

    RC: part of splitting up means that the compositing function and
    blending function are separate

    CC: what we said on the list was that there's no split of the model,
    the model only has one equation

    … the two properties control different aspects of it

    … the alpha-comp controls compositing modes

    … the blending property controls the F function

    RC: it's the other way around

    CC: let's work offline on this

    <ChrisL> Cyril: According to the current draft: src-in is
    f(Sc,Dc)=Sc and X=1 and Y=Z=0. Multiply is f(Sc,Dc)=Sc x Dc and
    X=Y=Z=1. So you are saying that when you use both the compositing
    and the blending modes, you keep the value of f(Sc,Dc) from the
    blending and you keep the X, Y, Z values from the compositing mode.

    RC: this splitting helps remove a lot of duplication

    <ChrisL> quote fromalex: "By separating out the blending from the
    P-D you get more

    <ChrisL> combinatorial possibilities that you couldn't do nicely if
    it

    <ChrisL> was one property."

    … in the spec it says a <g> introduces a new stacking context, but
    nobody does that

    RC: another one was simplifying porter duff by removing clip-to-self

    … we'll also add the missing blend modes from PDF/illustrator

    … there was discussion on whether to have knock out or not

    … we should clarify its purpose in the spec

    [rik draws to explain knock out]

    DJ: so it's almost like group opacity in some wys

    s/wys/ways/

    RC: it's the opposite of "isolate"

    DJ: it's like doing a clear of the shape in the group with knockout,
    before the blending operation happens for the child, so that the
    child only blends with the group's background
    ... for porter duff, how useful are they other than clear, srcover?

    CC: some designers use src-in, dst-in

    VH: I think originally porter duff was done for video, matting

    BB: I think also for tiling of images using atop to avoid seams is
    useful

    VH: I think from an implementation perspective, if you do one you
    may as well do all of them

    RC: I'm not completely convinced that porter duff should be in the
    spec, it feels a bit like a filter

    … it's already in the filters spec

    … in a way it makes more sense there

    DJ: but it doesn't allow you to clear an object, the way it exists
    in filters

    … the result of a filter is always src-over composited

    … if you want to knock out a background you can't do it

    RC: background doesn't really work with porter duff anyway

    … when you do compositing you don't look at the background

    DJ: what is this compositing with?

    RC: there are two images

    DJ: in SVG, you would say <circle id="a'/><circle id="b"
    comp-op="src-in"/>

    [vincent does some drawing on the board, and rik mentions that he
    proposed to remove clip-to-self property, and have clip-to-self be
    the default (only) behaviour]

    DJ: my next question, we don't do the missing blend modes

    … we don't have hue, saturation, colour blend

    RC: those ones only work on rgb, not cmyk

    … maybe that's why apple doesn't have them

    DJ: we are creating a new stacking context when you use a blend?

    RC: yes

    CL: on the mailing list, alex suggested a different name for comp-op

    … eventually he said what about "shape-mode" or "blend-mode"

    VH: we agreed in seattle to do a CSS Compositing spec, generic and
    not just SVG

    … I understand enable-background:new being the default for SVG, but
    it's less clear in CSS

    RC: any time you have a non src-over comp-op, you imply
    enable-background:new

    … that's new

    DJ: that's confusing

    <scribe> ACTION: Rik to write a small example explaining alpha comp
    and blending [recorded in
    [26]http://www.w3.org/2012/01/11-svg-minutes.html#action04]

    <trackbot> Created ACTION-3204 - Write a small example explaining
    alpha comp and blending [on Rik Cabanier - due 2012-01-19].

    ACTION-3204: explaining also how knock out and enable-background
    work with them

    <trackbot> ACTION-3204 Write a small example explaining alpha comp
    and blending notes added

    DJ: my main comment is, can we please have this in a spec?

    … I don't mind if people disagree with it, but currently you have to
    read one spec and 20 emails

    RC: ok

    … we might also reword the alpha compositing section of the SVG spec

    … wrt enable-background

    … I think the Filters spec is a lot more readable than what's in the
    SVG spec

    DJ: I think the spec needs to have more description for every
    property

    CC: I don't think I agree with the removal of clip-to-self

Web Animations

    BB: I have a proposal in light of the features we discussed this
    morning

    … that proposal is to make an element syntax that tracks CSS
    animations

    … in many ways

    … in terms of properties and behavior, matching names

    … but also borrows from SVG animation as well

    … it's a more fully featured CSS animations, in that it offers
    things with hierarchical semantics

    <ed>
    [27]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2012/Agenda/An
    imations/WebAnimations#Proposal:_Web_Animations

      [27] 
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2012/Agenda/Animations/WebAnimations#Proposal:_Web_Animations

    … compatct syntax, motion on a path, simple DO manipulation

    … I've called it Web Animations

    … I'd hope we could end up with one spec with two syntaxes

    … but the CSS syntax would probably be less fully featured

    … as Patrick mentioned, we don't want to overload the syntax to the
    point that it's a pain to use

    … from that core set of functionality, we only include the core
    stuff in CSS and the more complicated/sophisticated would only be
    available in the element syntax

    … the precedent for this arrangement is filter effects

    CL: I think that's a reasonable approach

    … the CSS guy are very concerned about simple use cases, authoring

    … they seem quite keen that if it gets too complex you go to
    something else (like element syntax)

    … I think that's a reasonable split

    BB: I think the other thing it offers is the ability to divide
    between semantics and styling

    … you can use CSS syntax for a presentational flourish

    … but for content you could use element syntax

    … what I'm proposing is the one model, moving easily between the two
    sytnaxes

    VH: I like the one model approach

    … one question I have is that in my expereince we have well known
    problems in animation

    … there's a timing model, animation value, the syntax is almost
    orthogonal from those

    … SMIL covers a lot of that

    … the animation engine really is going to say "here are properties
    that are animated, the from/to values, keySplines, iterations, etc."

    … could we agree to say that the precendent to follow is to reuse as
    much as possible the SMIL model?

    … but choose the best syntax for that?

    I'm sure SMIL is not perfect

    s/I/... I/

    … I'm afraid of going down the path of reinventing SMIL

    … I'd much rather do the easy way of using the SMIL model

    … I'm asking that for any aspects of the model we need, we take it
    from SMIL

    BB: I'm proposing something that learns from SMIL but is not bound
    by it

    … one of the big questions is to have something new that breaks
    compat

    … that's what I'm suggesting

    CL: I agree we shouldn't go off an reinvent the whole animation
    model, the stuff which has been proven to work we should reuse

    BB: I'm talking about breaking compat with SVG 1.1

    … introducing a new element that contains the simplified behaviour,
    more aligned with CSS

    … not building on <animate>

    CL: I'm less concerned about syntax than the underlying model

    BB: there are some things like how rounding is done differently

    … it's not easy to say in SVG2 rounding is done differently

    … that's why I'd prefer a new element

    CC: you'd throw away your animation engine in firefox?

    BB: no

    … in the future perhaps deprecation would allow removal of the old
    elements

    BB: I want to see if there's any agreement on that concept of
    defining a Web Animations spec

    -- adjourned --

    -- discuss more about this tomorrow --

    DJ: I'd like to see javascript apis too

Summary of Action Items

    [NEW] ACTION: Brian to link to the Seattle animation document from
    the Manly one [recorded in
    [28]http://www.w3.org/2012/01/11-svg-minutes.html#action01]
    [NEW] ACTION: Brian to prepare before and after examples of using
    time containers in SVG animation [recorded in
    [29]http://www.w3.org/2012/01/11-svg-minutes.html#action02]
    [NEW] ACTION: Erik to mail FX list with our acceptance of property
    proposal and to schedule a call [recorded in
    [30]http://www.w3.org/2012/01/11-svg-minutes.html#action03]
    [NEW] ACTION: Rik to write a small example explaining alpha comp and
    blending [recorded in
    [31]http://www.w3.org/2012/01/11-svg-minutes.html#action04]

    [End of minutes]
      _________________________________________________________
Received on Friday, 13 January 2012 06:47:46 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:50 GMT