RE: Minutes, 22 August 2013 SVG WG telcon

While ya'll are thinking about animation, remember the request from four or five years ago to allow, in addition to keysplines, the ability to have attribute values taken from drawn path coordinates, as was done in the ever-popular replicate proposal. It would be a far more intuitive way of allowing non-linear interpolations than keysplines, and ultimately, a far more precise and controlled way of managing things. Essentially it is like animating along a path, but for attributes other than just x and y.


-----Original Message-----
From: Erik Dahlstrom [] 
Sent: Friday, August 23, 2013 5:25 AM
Subject: Minutes, 22 August 2013 SVG WG telcon


and as text below:



                                  - DRAFT -

                       SVG Working Group Teleconference

22 Aug 2013



      See also: [3]IRC log



             [IPcaller], krit, Doug_Schepers, ed, birtles, heycam,
             Rich, nikos, +1.425.373.aaaa, Tav





        * [4]Topics
            1. [5]Review of comments on css3-fonts
            2. [6]css3 cascade review
            3. [7]Animation of CSS Filter Functions with url()
            4. [8]SMIL animations on CSS filter property and filter
            5. [9]Review request on SVG 1.1 SVG filters
            6. [10]Should color values in all our specs be between
               0.255 or 0..1?
        * [11]Summary of Action Items

      <trackbot> Date: 22 August 2013

      Zakim: +jimsch is me

      <birtles> Zakim: [IP is me

      <heycam> Agenda:


      <scribe> scribeNick: ed

Review of comments on css3-fonts



      CM: csswg had requested our comments on css3 fonts, due today
      ... put together chris and my comments on that wikipage
      ... first, have tests for features, and to convert them to svg
      ... second, svg in opentype, selecting colors from the font or
      from outside, just to keep this in mind for next level of spec
      ... the rest seems good to me

      krit1, BB: sounds good

      <richardschwerdtfeger> +1

      CM: ok, if everyone is happy then I'll send our comments

css3 cascade review

      krit1: no incompat to svg spec
      ... scoped styles introduced in html5, and css defines how they
      interact with cascades... would be nice to add to svg moving
      ... but no specific comments on css3 cascade spec from the svg

      CM: will you send a mail to www-style say that we're happy with

      krit1: sure

Animation of CSS Filter Functions with url() function

      krit1: just added filter functions, can interpolate as long as
      the types match
      ... shorter list can be interpolated with longer lists by
      appending to the end of the shorter list
      ... question is: can we tolerate a url but interpolate things
      around the url()?
      ... <explanation about time jumping and interpolation (missed)

      CM: follow same rules as ...?

      krit1: similar to transforms interpolation, falls back to full
      interpolation of matrices
      ... but something like that isn't possible with filter
      ... some have just length values which are easy to interpolate

      CM: we might get the same problem with marker patterns too,
      interpolating between url and some values

      krit1: yes, it would be the same problem

      CM: with SMIL, does it switch half-way through?

      krit1: you have a timing function, f(t)
      ... the function defines if you should jump or not

      BB: once you swithc to discrete you ignore
      ... any keysplines

      CM: if you have calcmode something else, can you interpolate?
      ... are we the same as CSS animation?

      krit1: SMIL animation is different

      BB: the models are compatible

      krit1: both can be done with the same timing model

      BB: in svg the output doesn't take keysplines into acconut in
      discrete mode, but in css it does

      krit1: we have a resoltuon in the csswg about this, but it
      hasn't been included in the specs yet
      ... for properties that have enums

      CM: in the future the spec will say it does the switching?

      krit1: yes

      CM: in that case it should be fine to let filters behave like
      that too
      ... can you interpolate between a longer and a short list if
      they have the same types?

      krit1: yes
      ... it's specified how that should work

      CM: ok, happy with that then

      krit1: what do others think?

      DS: sounds fine

      RESOLUTION: url on filter property can be interpolated with
      discrete animations

SMIL animations on CSS filter property and filter functions

      krit1: when you look at svg, we had similar bugreports in

      <birtles> [14]




      krit1: if we look 19.17





      krit1: sorry, 19.2.17
      ... there you have the datatypes that can be animated
      ... we don't have filter functons there
      ... SMIL animations can interpolate same as css animations

      CM: as david baron suggested, filter spec should say how to
      ... not sure what to say in svg spec itself
      ... will work how that should look

      krit1: just reference the filter effects (how they can be

      CM: we wouldn't have to refer to filters from svg

      krit1: but you have to find all specs to find the animatable

      CM: but then you have to update two specs and keep them in sync

      DS: question, about timelines, brian you'd be the one to put
      new animations in svg?
      ... do you feel like it's an svg2 thing, or an svg3? or a

      BB: prefer a module, don't want to hold up the svg2 spe

      DS: what kind of timeframe do you have for mapping the svg
      animations to the new animation model?

      BB: within the next year

      DS: would be good to have something to review, in parallell
      with svg2 being finalized
      ... just to let ppl know that declarative animations aren't
      ... we've talked about letting svg2 be the core spec, and
      letting svg2.1 be the svg spec + some modules
      ... animations might fit in there pretty well, your timeframe
      seems reasonable

      tav: how are you supposed to animate a 'width' in the future?

      BB: the proposal is to promote that to a property, and to
      animate that
      ... focused on properties
      ... so try to promote most things to properties, where it makes

      krit1: the table with types, should I add that to the filter

      BB: yes, seems reasonable

      <scribe> ACTION: krit to add filter function data type for
      declarative animations (to the filter effects spec) [recorded
      in [18]]

      <trackbot> Created ACTION-3519 - Add filter function data type
      for declarative animations (to the filter effects spec) [on
      Dirk Schulze - due 2013-08-29].

      krit1: are filter functions additive? and can they be paced

      Tav: don't understand the second one

      CM: intrinsic notion of ... between values, constant velocity
      ... or speed

      krit1: would be a timing function, think it's keypoints, but
      not sure

      CM: yeah, duistance between the values

      BB: not sure theres a disctance between filter values, if
      there's not then there's no reason to do paced

      krit1: length and ... can both be paced

      BB: if you have the same types then yes
      ... apart from transforms, color aslo has interesting distance



      BB: there are the definitions for hte diff data types
      ... that DOH wanted

      DS: did we ever anticipate animating between not having a
      filter to having a filter?

      CM: think that was covered with animating between 'none' and
      some other values, and dirk said it would work

      DS: does it only work fro url filters, or jst shorthand

      krit1: just shorthands

      DS: animating between my own drop shadow and my own blur, and
      transitions from regular HSL to sepia

      krit1: not really possible, unless you have custom filters,
      with custom variables that you can animate
      ... svg parameters might let you do that too

      DS: got distracted when svg params seemed similar to css
      ... if we want to do something with svgparams we should go back
      and look at use-cases

      krit1: ok, but it's a different discussion

      BB: back to additive and paced, makes sense to be both

      CM: when it makes sense to be additive, would it add or

      krit1: you'd look at the distance functions
      ... you'd look at the two filter functions

      CM: right, but for adding, it's smetimes different how things
      are additive
      ... like scale and translate, postmultiply and add
      ... so maybe we should look at where it makes sense to do what
      and in which contexts, for filter functions

      krit1: maybe, I have no idea what would make sense here

      CM: having animations for filters is similar to transforms
      where you want to concatenate two lists, for additive

      BB: hmm, yeah, might make sense

      CM: what's the diff between paced and additive?

      krit1: the distance function

      CM: don't think additive needs the distanec function
      ... don't think that's necessary

      BB: yeah, distance is only used when doing paced animation

      krit1: not sure how ... could look like

      CM: should I write up how I think it should work, and send to

      krit1: yeah, sure

      <scribe> ACTION: heycam to write up how additive animations
      should work on filter functions, and send to www-svg [recorded
      in [20]]

      <trackbot> Created ACTION-3520 - Write up how additive
      animations should work on filter functions, and send to www-svg
      [on Cameron McCormack - due 2013-08-29].

Review request on SVG 1.1 SVG filters

      krit1: I'm cleaning up the filter functions
      ... if anyone have some suggestions for how to write
      descriptions of filter functions in a more clear way please
      send to the public mailinglist

      CM: yes, hard to understand what the filter functions do by
      looking at the algorithm code in the spec
      ... what stage is the filter spec atm?

      krit1: i think we published second WD

      CM: should we not review the spec as it is right now?

      krit1: not until tomorrow at least
      ... i'll ping you next week
      ... by request on peter linss I have some more issues that i'll
      bring up next week

Should color values in all our specs be between 0.255 or 0..1?

      krit1: svg filters defntions not always clear which range we

      Tav: one problem with 255 is that you can't have half

      DS: anyone disagree with 0..1 is the better way?

      Tav: maybe backwards compat?

      DS: it's only a spec-level change, shouldnt affect the

      tav: how do we deal with displacement map, it's to 0..255,

      CM: we're only talking about the spec definitions, right?

      DS: yes, but in authoring practice
      ... but we should resolve on using 0..1 for colors
      ... and then we should look at where we use 0.255 in the spec

      tav: would like the lighting filters, where you have
      discontinuities, produces steps
      ... you get a bump
      ... you get angles in your bump maps

      DS: we could use a functions, instead of rgb we could use hsl,
      or some value

      tav: would like to see it addressed at some point

      DS: put forward a proposal?

      tav: red value for x direciton, blue for y direction, but you
      define the bumps in terms of color
      ... <tries to find example>



      DS: maybe we should first have a proposal?

      tav: you can see the effects on that page

      krit1: do you want the artifacts, or smooth?

      tav: smooth
      ... you define the map as a png or a bitmap or whatever

      CM: the intermediate thing you render to, are you allowed to
      have something more precise that you input to the lighting

      tav: right

      CM: in our internal operations in the spec we should use 0..1,

      all: yes

      RESOLUTION: we must always use 0..1 for color values in svg

      <shepazu> s/sould/must/

      CM: this comes up in filter primitive definitions?

      krit1: would be good to specify in the beginning

      trackbot, end telcon

Summary of Action Items

      [NEW] ACTION: heycam to write up how additive animations should
      work on filter functions, and send to www-svg [recorded in
      [NEW] ACTION: krit to add filter function data type for
      declarative animations (to the filter effects spec) [recorded
      in [23]]

      [End of minutes]

       Minutes formatted by David Booth's [24]scribe.perl version
       1.138 ([25]CVS log)
       $Date: 2013-08-22 21:37:48 $


Scribe.perl diagnostic output

      [Delete this section before finalizing the minutes.] This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11 Check for newer version at [26]


Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/CM/BB/
Succeeded: s/CM: if you have/BB: if you have/
FAILED: s/sould/must/
Succeeded: s/should/must/
Found ScribeNick: ed
Inferring Scribes: ed
Default Present: [IPcaller], krit, Doug_Schepers, ed, birtles, heycam, R ich, nikos, +1.425.373.aaaa, Tav
Present: [IPcaller] krit Doug_Schepers ed birtles heycam Rich nikos +1.4 25.373.aaaa Tav
Regrets: Chris
Agenda: [27]
Found Date: 22 Aug 2013
Guessing minutes URL: [28]
People with action items: heycam krit


      End of [29]scribe.perl diagnostic output]


Erik Dahlstrom, Core Technology Developer, Opera Software Co-Chair, W3C SVG Working Group Personal blog:

Erik Dahlstrom, Core Technology Developer, Opera Software Co-Chair, W3C SVG Working Group Personal blog:

Received on Friday, 23 August 2013 11:02:02 UTC