SVG Working Group Teleconference -- 22 Aug 2013

<trackbot> Date: 22 August 2013

Zakim: +jimsch is me

<birtles> Zakim: [IP is me

<heycam> Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2013JulSep/0060.html

<scribe> scribeNick: ed

Review of comments on css3-fonts

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/Review_comments_on_css-fonts-3_2013-07-11

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 tests
... 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 forward
... but no specific comments on css3 cascade spec from the svg POV

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

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 functions
... 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 mozilla

<birtles> http://www.w3.org/TR/SVG11/animate.html

<birtles> http://www.w3.org/TR/SVG11/animate.html#AnimationAttributesAndProperties

krit1: if we look 19.17

<krit1> http://www.w3.org/TR/SVG/animate.html#InterfaceTimeEvent

<krit1> http://www.w3.org/TR/SVG/animate.html#AnimationAttributesAndProperties

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

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

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

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

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 dead
... 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 sense

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

BB: yes, seems reasonable

<scribe> ACTION: krit to add filter function data type for declarative animations (to the filter effects spec) [recorded in http://www.w3.org/2013/08/22-svg-minutes.html#action01]

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

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 type

<heycam> http://www.w3.org/TR/SVG/animate.html#complexDistances

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

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 variables
... 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 multply?

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

krit1: yeah, sure

<scribe> ACTION: heycam to write up how additive animations should work on filter functions, and send to www-svg [recorded in http://www.w3.org/2013/08/22-svg-minutes.html#action02]

<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 use

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 implementations

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

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>

<Tav> http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Filters-Lighting.html

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 filter

tav: right

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

all: yes

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

<shepazu> s/sould/must/

CM: this comes up in filter primitive definitions?

krit1: would be good to specify in the beginning

trackbot, end telcon

- DRAFT -

SVG Working Group Teleconference

22 Aug 2013

Attendees

Contents