- From: Cameron McCormack <cam@mcc.id.au>
- Date: Fri, 13 Jan 2012 17:44:38 +1100
- 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:44 UTC