Minutes, FXTF F2F Hamburg 9 May 2012

Minutes in html format attached, and the same as plaintext below.


FXTF F2F in Hamburg
09 May 2012

Topics
Transitions/Animations: New animation proposal
Web Animation proposal
CSS Transform update
CSS Compositing and blending
Filter effects
Test the Web Forward
SVG attributes becoming properties
Agenda
Transitions
Transforms
Animations
Summary of Action Items


Web Animation proposal

  <dbaron>  
http://people.mozilla.org/~bbirtles/web-animations/presentation/web-animations.html

brian: presenting the work done on Web Animation. Work done with Shane,  
Rik, Tab, Dmitry, Alex, Vincent.
  ... trying to focus the animation effort. What we are proposing is a  
script API that underlies both specs.
  ... the CSS and SVG animations can be implemented in terms of that API.
  ... the API can be useful as is to script authors as well.
  ... we hope that as a result of this, there will be a single place to  
focus for animation efforts.
  ... I want to reflect on the initial problem we are trying to solve.
  ... going through the presentation at  
http://people.mozilla.org/~bbirtles/web-animations/presentation/web-animations.html
  ... discussing limitations of SVG and CSS animation models.
  ... Proposing to have script extensible declarative animations.
  ... three specifications: the Web Animations API and two specs.  
explaining the mapping of SVG and CSS animations to that API.
  ... In the model, an animation 'template' can generate multiple animation  
instances for various targets.
  ... Another key concept is grouping of a series of animations. Lets you  
sync. different animations. Can have a parallel group and a sequential  
group.
  ... you can nest groups.
  ... Also have a notion of template on the AnimGroup  
(AnimGroup/AnimGroupInstance)
  ... Model that underlies the proposal: Timing Model and Animation Model.
  ... there is a hierarchy of timelines.
  ... the nice thing is that you can use the same timing on a group or an  
animation.
  ... the timing model has a start time and a start delay. This allows  
support of the SVG timing model and more intuitive models.

glenn: can you have negative start time and negative start delay?

brian: yes. This is compatible with what is done in CSS.

  <dbaron> (I think he said you can have a negative delay, but a negative  
start time doesn't make as much sense.)

  <shanestephens> vhardy_: brian's response was "yes for negative start  
delay, but negative start time isn't useful"

liam: is this about path morphing or motion animation?

  (several): motion animation (move along a path)

jet: does the model define a sprite model?

alex: no

brian: there is a mapping between the CSS declarative animations and the  
objects.
  ... similarly for SVG. The SVGAnimationElement interface inherits from  
Anim (from this new API)
  ... some features are not included (such as sync. base timing).
  ... some features in the API are not in SVG yet and hopefully will be  
exposed in SVG 2.

heycam: if you can declare an animation with sync. base but you can still  
interact with it, will that work?

brian: you could have more APIs in the SVG specific subclasses that could  
expose the sync. base graph for example.
  ... there is a link to the current draft that is work in progress. There  
is a pointer to the CSS integration draft.

  <dbaron>  
http://people.mozilla.org/~bbirtles/web-animations/web-animations.html

  <dbaron>  
http://people.mozilla.org/~bbirtles/web-animations/css-integration.html

brian: I would like to hear comment about the reaction to the approach.

krit: I have questions about the limitations. I disagree with the  
limitations you listed for SVG.
  ... animations in SVG are re-usable. You can re-use them with <use>  
element.

heycam: you can use the element, but not the <animation> element.

krit: you can point to an animation from a <use>
  ... you can synchronize the start/end of animations.
  ... I would be interested in CSS transitions to sync. with the beginning  
and end of transitions.
  ... in CSS, the timing parameters do not change after the start of the  
animation/transition.

brian: this is still in discussion I believe.
  ... we are incorporating a model where the template has a relation to its  
instances so that if you change the template, the instances get updated.

krit: about accumulation, it needs to be specified for each property type.  
e.g., transform. Where should the accumulation model should be defined?

brian: I think it makes most sense in the relevant spec. (e.g., CSS  
transform for the transform property).

krit: we are doing it for transform now, but I think it should be in the  
combined web animation spec.
  ... it should be in CSS transition as well.

brian: I am not sure we can capture all the data types we will ever need.

dbaron: it think we already agreed to add the animatable entry in all new  
properties and for existing properties, it can be in the transitions spec.

krit: the web animation also specifies the relation to CSS cascading?

brian: yes.

glazou: questions. Web authors already complain about the process for CSS  
animations and transitions. Will this delay these specs?

brian: no.
  ... it will not have any impact.

dbaron: you mean this is something we are doing for the next level?

brian: the CSS animations and transitions should not change as a result of  
these specs.

dbaron: I would like to advance these specs as they are and then we  
incorporate in the next level of these specs.

tab: I think brian's model is compatible with what you say. If we wanted  
to plug into the web animation spec. we could, but we do not need to touch  
these specifications at all.

glazou: do you think this is a ground layer or is it something new?

  which do you expect authors to use.

brian: an implementation of CSS level 3 animations/transitions can be  
implemented with this new API or not. The specs. do not change. The APIS  
can be exposed, but this does not interfere with the behavior of the  
declarative animations.

shane: all the CSS OM would still work.

glazou: you would have multiple implementations on the market, some with  
the new API and some without.
  ... once this is in the wild, you'll have incompatible support in  
browsers.

tab: this is laying the ground for a model and does not change the  
behavior of the current specs.

glazou: given its simplicity, people will start using it, and browsers not  
implementing it will be left behind.

sylvaing: how is this specific to this proposal compared to other  
proposals?

glazou: animations are already used.

szilles: is your point that the API could create confusing for authors?

sylvaing: I think people will use the most interoperable.

tab: this is just adding a new API to do animations in JS in addition to  
CSS.

dbaron: it might actually help to call the part that integrates with CSS  
animations and transitions level 4.

glazou: what you miss is the serialization of CSS animations from the API.  
The tricky part of your API is that you can animate any element, it is not  
bound to a CSS selector.

  (discussion on serialization).

brian: .. this is something we have discussed but that is not in the spec.  
currently.
  ... if you manipulate CSS and/or SVG animations, these are still  
serializable after manipulation through API..

tab: I am not sure we have to worry about people doing things in JS and  
serializing.

glazou: I am thinking of editors.

tab: it could be serialized to CSS.

brian: I think this is a valid point, we need to look at serialization.

shane: I think we could add support for serialization.

brian: this is good feedback.

florian: shane had made a presentation a few F2F meetings ago. Where is  
that?

shane: much of the material I presented then, did not make it to the  
specification, but it could be added.

brian: we had a section in the spec, but decided to leave it out for the  
first iteration.

vhardy: is there a shim for that?

shane: I am working on it, it will be available.

dbaron: there was a discussion about cascading?

krit: I wanted to know if there was a good definition for that? There is  
SVG animation, CSS animation, CSS transition and not a good model for how  
all that cascades.
  ... what happens if they happen at the same time on the same property?

shane: the answer there is that we have a model to address this. One  
replaces the other.

krit: I think this is more complicated than that from the cascade point of  
view.

dbaron: I think there is a good reason for css transitions to be on top  
because they operate on computed value.
  ... the fact they are on top usually won't show up because they do not  
react to computed value changes.

krit: if there is an inline style specified on :hover, it would override  
the transition (on the same property)

dbaron: no, it will not override the transition and I am pretty sure it is  
interoperable.

florian: would it be interestesting to work on this while considering them  
to be level 4. Instead of having other specs figuring out the declarative  
model, we could combine the work. The idea of the model is not  
incompatible with adding new markup.

brian: for the case of SVG, this is what we are thinking of doing.
  ... there are some things that we are thinking could be added to CSS  
syntax as well.

florian: I am thinking that once we build the model, we could first figure  
out the CSS syntax for it. Then, we move on to API work.

brian: we have gone through that process, for example for groups.
  ... it could be worth going through this again.

  (discussion about where transitions fit into the cascade).

dbaron: transitions only start when the computed value changes.
  ... if you have a rule that is so strong the computed value never  
changes, the transition never happens.

ed: what is the next step?

brian: is this something we should continue?

heycam: last year, when we talked about resolving the differences between  
the CSS and SVG animation modles, but I think exposing the JS model is  
very useful.

florian: I think considering how it can be done declaratively is not quite  
enough.
  ... people will ship the API before there is a declarative solution.
  ... we should also define what the new markup should be (e.g., how do you  
use it with CSS animations/transitions and SVG animations). I do not want  
the animation API to get too ahead of the declarative solutions.

glazou: the CSS wg is about CSS, not about script. Script is an extra tool  
on CSS itself. The main thing is CSS. I tend to agree with Florian. I do  
not want people starting writing scripts because the declarative script is  
not ready.
  ... I see more people using CSS animations than JQuery animations.

tab: CSS animations were not designed for advanced animations. The JS api  
is designed for that.
  ... the sort of things people are hacking css animations for today, we  
want to help with/correct.
  ... things are painful right now.

ted: people are animate things declaratively and imperatively.
  ... they'll do it both ways and it is good to rationalize the model. It  
seems like a win to me.

glazou: may be we missed features in the current CSS  
animations/transitions specs.

shane: we are in a good position to describe what is missing in the  
current spec.
  ... there is a mismatch between what some people want to do and the  
available features.

glazou: the CSS wg never really worked on this problem.

florian: working on the underlying model is good, but the focus should be  
on declarative markup before the API.

glazou: what is the commitment of browser vendors on this work?
  ... what is the commitment?

jet: if we are contemplating new animation functions v.s., this new model,  
we would do the new model first.

glazou: so this is level 3 for you, not level 4?

  (discussion about Mozilla's interest in the specification ...).

dbaron: I would not draw a hard line here.

vhardy: we will participate in the specification work with Dmitry  
Baranoskiy

ed: I think it is early to commit, but this is interesting.

florian: this is interesting, but I am not sure we would do it soon. It  
looks nice.

sylvaing: this seems to go in the right direction.

brian: can we continue working on this?

glazou: can we have a JS library for this?

shane: I am working on this.

vhardy: there are current limitations with the CSS animations and  
synchronization.

glazou: bert is the gatekeeper of CSS declarative support.
  ... this is the first time that we are saying that we are going to  
replace script by script.

brian: this is not just the CSS wg, this is the FX task force.
  ... I am convinced about the power of declarative solutions, but we  
recognize that declarative markup has limits, and people will in some case  
step into scripts. Will we help them there.

glazou: I am not sure that declarative solutions have limitations.  
Eventually, we have always succeeded in the past.
  ... e..g, variables.
  ... eventually, the last proposal is well integrated in the spirit of CSS.

florian: it is hard to find simple solutions.

glazou: a declarative solution for animations, sync. is possible. Just  
hard to find.

florian: I agree that only when you hit the limit of declarative markup,  
you get to script.

brian: even with the 10year long SMIL work, there are still cases where  
you need to resort to script.
  ... we should make it so that the script API can be consistent with the  
declarative solution and integrates.

florian: we can look at what people do with scripts, build the underlying  
model, expand the declarative syntax and then add an API.

alex: the most important part of this spec. is the model we are trying to  
define.
  ... I prefer declarative too. We are trying to fix that you cannot  
synchronize, priorities on animations, make something that covers the CSS  
animations, transitions and SMIL model.
  ... this is what we are trying to get right. Whether this is expressed as  
script or declarative, this is an orthogonal problem.

glazou: I think we should formally answer brian's question.

RESOLUTION: The group accepts Web Animation as a work item.

brian: there are 3 specs. the model with the API, the CSS  
animations/transitions in terms of that model and a third for SVG and this  
model.

florian: would the CSS part become part of CSS Animation Level 4?

brian: this is up to the CSS wg. dbaron has suggested it.

glazou: should we have a single document?
  ... you could start editors draft separately, but you could join them  
later.

  (several agree).
CSS Transform update

krit: we had a discussion about the SVG part of CSS transform.
  ... here is the list of general CSS issues.

  <ed>  
https://www.w3.org/Bugs/Public/buglist.cgi?product=CSS&component=Transforms&resolution=---

  <ed> http://dev.w3.org/csswg/css3-transforms/

krit: for the 3D part, I am relying on the other editors. There is a  
problem with the perspective.
  ... the editors are still unsure how to address the issue, we are waiting  
for more implementation feedback. The other issue is about the containing  
block.
  ... we re-wrote some parts like section 14 (The Transform Functions).
  ... the SVG and 2D issues can be addressed in the next two weeks. The 3D  
issues require more feedback from implementors.

ed: do you want a resolution to publish?

krit: yes. Many things have been updated. There are a few issues remaining.

ed: everybody fine with publishing a new WD

RESOLUTION: The task force agrees to publish a new version of the CSS  
Transform specification draft.
CSS Compositing and blending

  <ed> https://dvcs.w3.org/hg/FXTF/raw-file/tip/compositing/index.html

rik: talking today about compositing and blending in css and canvas

  … nikos and I have been working on a spec to integrate this into the  
browser world

  … why do we want to add this to the web platform?

  … designers already use this

  … they want to use it in web tools

  … currently they must rasterise

  … so it'd be better to support this natively

  … another reason is that it is easy to describe in css

  … the math behind it is complex, but how you write it in CSS is simple

  … the third reason is that it's pretty easy for browser vendors to  
implement

  … looking at firefox/webkit, it's implemented in software

  … windows 8 exposes an api to do it natively

  … there was an SVG spec before, tailored towards SVG

  … we're trying to have a spec that just describes the model

  … it doesn't talk about in what world (SVG, CSS, …) it happens

  … it doesn't talk about buffers, just shapes

  … the previous spec used similar formulas for compositing and blending,  
which made them complex

  … so we pulled them apart

  … blending you can imagine as a painter mixing colours on a palette, and  
compositing is laying it down on a canvas

  … the second part of the spec is how it applies to CSS and SVG elements

  … thirdly, how this applies to the CSS box model

  … fourth, optionally, how this applies to canvas

  … there is already a globalCompositingOperator, so we're looking at  
extending that

  … the spec defines alpha compositing, describing how this works today

  … it talks about how the background is calucated, how to use group  
isolation

  … it also talks a bit about group invariance, which means that you can  
add grouping to any set of elements and it should not make a difference to  
the display

  … you'd think this would be straightforward, but it causes some subtle  
side effects

  … if you change the opacity of a group, you wouldn't expect the child  
elements to render differently, but in flash which doesn't have group  
invariance it does

  … another part the spec goes over is group alpha

  … which is described as applying the alpha to all elements in the group,  
without inheritance

florian: is a group a set of elements matched by a selector?

rik: no it's an element, like a <div> or a <g>

dbaron: opacity is group opacity, that definition of "group"

tab: what's an example of how lack of group invariance affects things?

rik: if you have two overlapping circles in a group, setting opacity on  
the group will cause the top circle to interact with the bottom circle

  … the next section talks about porter-duff

  … this is primitive blending operations

  … firefox and webkit have this under the hood

  … and we want to expose it to the API

  … we go over all the porter-duff modes, we're not changing anything from  
their standard definitions

  … we talk about how they work with groups

  … and what happens when you have porter-duff in an isolate group

  … we also discuss knockout behaviour

  … and clip-to-self

  … the next section, which is pretty much done, talks about blending

  … which is the PDF rendering model

  … it lists all the separatble and non-separable blending modes

  … the separable modes are ones that apply to the red, green, blue  
channels separately

  … non-separable ones convert to hsl, then performs the operation

  … the spec has some pictures indicating how these blending modes work

  … it also describes how blending interacts with groups and isolation

  … and again how knockout behaviour works

  … the next section is how you use this from css

  … we define a bunch of porter-duff css keywords for use in an  
'alpha-compositing' property

  … (which are also used in canvas)

  … and the 'enable-background' property, which came from the SVG world

  … it might've been added to the filter shorthands?

alex: no

rik: [demos]

  [some discussion about clip-to-self, and how for css content clip-to-self  
will always be true]

  [as opposed to SVG content]

rik: then we have the keywords for blending in CSS

  … we have a 'blend-mode' property, which has keywords normal, multiply,  
screen, ...

  … the 'isolation' property auccumulate | isodlate

  … and 'knock-out' preserve | knock-out

  … [demo of blend modes with two photographs]

  … [demo shows black text with a drop shadow, with a transition on it, and  
the shadow interacts with the image behind it to take on its colour,  
resulting in an embossing effect]

dbaron: is there a group for the blending, or the alpha compositing?

  … there are lots of things in CSS where there's a composite drawing  
operations

rik: for background images?

dbaron: drawing borders it's not precisely defined if there's overlap, or  
two separate things that overlap

rik: all of those things are considered part of the group

dbaron: even with alpha-compositing?

rik: yes
  ... we're going to propose a keyword that lets you control things within  
the group

  … the section of the spec that talks about html, we should mention that  
any element is a group

nikos: any discrete thing is a group

dbaron: there's a separate group for the text and the shadow?

rik: no, they're in the same group

vhardy: the broders, background, shadow all form a graphical group

dbaron: so this proposal doesn't involve change the rendering within a  
single element's parts?

rik: yes but this keyword later can change this

  … designers have said they want this behaviour

vhardy: having a different blend mode for the shadow and the element, for  
example

rik: [demos an image blending with itself]

  … photoshop users often do this to beef up the contrast

  … [demos blended video]

  … now we come to how to do blending within a css box

  … this is a bit up in the air still

  … we're thinking of having a 'background-alpha-compositing' property,  
which gives you a list

  … list of porter duff operators, one for each background

  … 'background-blend-mode' for how they blend to each other

  … three other properties: 'box-shadow-blend-mode',  
'text-shadow-blend-mode' and 'foreground-blend-mode'

  … I don't like that there are so many keywords

  … maybe they can be collapsed into one

heycam: referencing the differnet parts of the css boxes is like what I  
wanted for the paint-order operator in SVG

  … but there I had the parts of the SVG element in the property value, but  
here you have them in the property name

vhardy: it could be in the value here too

dbaron: is foreground-blend-mode applying to all contents, or just some?

  … as in not within some other child element?

  … so if you had an inline element inside the p, it would or wouldn't  
apply?

rik: it would apply

dbaron: I actually prefer not separating the contents

heycam: and the borders and backgrounds of the child elements are  
considered the contents of the original element?

rik: yes

  … we haven't implemented these three properties yet

  … next we have keywords for adding blending to canvas

  … we can extend the list of porter-duff operators in globalCompositeMode

  … should it be separate?

dbaron: I don't understand the separation between alpha compositing and  
blending mode

rik: blending works on the colours, and then this result is alpha  
composited on the destination

dbaron: both of these seem to be functions that have two inputs and one  
output

alex: the difference is alpha compositing affects the alpha channel, blend  
modes only affect colour channels

dbaron: the alpha compositing does affect the colour channels

alex: but only in terms of how much it lightens

  … you're multiplying red * red, blue * blue, green * green

  … alpha compositing with opacity=1 is just the source

  … as you drop alpha, it changes the colour

  … with a blend mode, even if completely opaque, it can affect the colours

  … when you apply alpha it's all done at the one time

rik: are you tripped up because you think you need to look at the  
background twice?

tab: it's just that the math looks similar

alex: alpha compositing is just blend mode with function=1

vhardy: you don't have to implement them as separate steps, you can  
combine them

  … it's common mental model for designers to think about these things  
separately

rik: and it makes things easier to describe

  … in the SVG spec it was complex because it treated them both at the same  
time

  … and you don't really have to specify the result in the spec

vhardy: also often we expect people just to use blend modes, they're more  
likely to be used than porter duff

tab: i doubt porter duff be that useful in css, more useful in svg

rik: [demos example in firefox this time of canvas blend modes]

  … we have prototype implementations for webkit, chromium and firefox

  … in chromium we use the gpu

  … there are some issues in the current spec

  … you should read the spec first before we can have a conversation about  
them

  … right now, group isolation applies separately to blending and  
compositing

  … but that might make implementations more difficult

  … if you have isolation apply to both compositing and blending at the  
same time, it gets easier to calculate the background

  … which you'd need to do twice

  … the same applies to knock-out

  … also, there are too many keywords for blending/compositing inside the  
css box

  … if you just want to specify a blend mode on the text shadow, it should  
be concise

  … people also seem to be more in favour of having a separate property for  
blend modes

  … another question is should the spec be split, model from css/canvas  
details?

  … similar to the animations discussion this morning, it might be good to  
split it out

florian: that would only be useful if you want the model to reach REC  
before the css syntax

dirk: perhaps so you could use it just in canvas before css, too

rik: I'm neutral on the splitting

florian: I'd say don't split yet

rik: we have working prototypes

  … for chromium we have hardware acceleration

  … in webkit, it calls into Core Graphics

  … in Firefox it uses Core Graphics on Mac, but on Windows we haven't done  
the Direct2D backend yet, so it uses software

  … we're pretty close to being able to publish a WD

  … the porter duff section needs to be clarified a bit

dbaron: this has a three sentence definition of the enable-background  
property

  … which I remember being really complicated in SVG, and I think  
supporting it in CSS would require making it even more complicated

  … I think it's pretty close to working in CSS, but not quite

rik: the keyword or the model?

dbaron: I'm looking at the "The enable-background property" section

  … it should be described earlier in the spec how the background is  
calculated

vhardy: there are more than three sentences

nikos: in section 3

dbaron: these sections should point to each other to some extent

  … the section just seems to be given examples, not a specification on how  
to do it

rik: the background is basically everything that is rendered before

dbaron: that doesn't explain what happens if you're in a group and the  
background is outside the group

  … that's the bit in SVG that has very complicated rules

alex: you're talking about accumulate with porter-duff?

dbaron: there's the set of rules for SVG filters

rik: it's the same rules

  … if you look at it, it's a long 6 step process, but basically it's just  
"take what was rendered before and composite over"

dbaron: CSS isn't so precise about "before" and "after"

rik: in Firefox you compose a group and then composite it

dbaron: but that's when there is a group, this blending happens on top of  
things which aren't in the group

rik: enable-background creates a new stacking context

  … that's something that's not there today

  … everything browsers do currently is accumulate

  … the background calculation will take some time to do

  … in the group you have blending, you have two half rendered graphics,  
which you source over, then composite to the background

dbaron: my memory of the SVG rules is that there's something in there that  
assumes there's a separation between container elements and things that  
draw

  … and the rules in SVG don't quite work when you have something that is  
both a container and draws stuff

tab: SVG definitely does make that distinction

dbaron: the wording of those rules would need to be updated

  … they'll need to be a bit more complex than what's in SVG

  … it's been a while since I've looked at it

alex: you're tlkaing about the filter input that's BackgroundImage

  … that's only to do with SVG Filters

  … if you explicitly use that keyword, you need to ensure there's a  
background store somewhere up the chain

  … so you have to put an enable-background:new somewhere up the tree

  … but blending doesn't require that

  … so in effect it's always enable-background:accumulate in CSS/HTML

dbaron: how does compositin on top of what's underneath work if you're  
inside a group?

rik: you render the group first, then that group is blended/composited  
with what's behind

dbaron: the blending happens only with what's in the group?

rik: it applies to the rastered parts of the group

alex: blending is different from filters

dbaron: so why is enable-background in the draft?

rik: in case you want to create a new stacking context

  … in a PDF with artwork you might not want that to interact with other  
things in the page

dbaron: give it a stacking context or its own group?

alex: stacking context is the wrong term

  … it's a new rendering surface

dirk: so you draw the group into a new bitmap

dbaron: it's like a new group

rik: if you have a rectangle inside a group with enable-background:new, it  
will not multiply with content outside of it

dbaron: so enable-background:new forces creation of a new group

  … it's essentially like saying opacity:0.9999

alex: yes

dbaron: except it also has this effect on SVG Filters

alex: the complication for SVG Filters is that some of the primitives  
require a backing store, so you need this enable-background somewhere

  … but that's orthogonal to this

dbaron: it seems like if there needs to be a mechanism in this document  
for "force there to be a new group", "enable-background" might not be the  
thing to do it

  … does alpha compositing apply to individual drawing operations or to the  
element as a group?

alex: not sure what you mean

nikos: both I think

rik: if you specify it to the group, it applies to the group not its  
children

dbaron: the alpha-compositing property applies to all elements

  … src-over has this nice property that it's the way we draw everything  
normally

  … but once you pick another one of these values, it matters how it applies

  … it matters whether you draw the background and the border into the  
surface, and then using the alpha-compositing property to composite that  
on to something else

  … or whether you're doing each of these drawing operations with the  
porter duff mode

  … is blend mode the same way?

alex: yes

dirk: Filters also defines enable-background, should it share the  
definition somehow?

rik: the one in the Filters spec talks about buffers...

dbaron: there's nothing in apart from this section that references  
enable-background?

  … if I search for enable-background in this spec, it's only in 6.2.2 The  
enable-background property

  … which has just three sentences

rik: that needs to be fixed

nikos: in general there's not enough description of groups and how that  
interacts

alex: or even of what enable-background does

rik: that's why I said the section on Porter Duff needs to be expanded

  … since it doesn't talk about groups

alex: but enable-background doesn't actually talk about what it does

rik: so it needs to reference the model, and the model needs to be updated

dirk: can it reference Filters?

alex: they're for different purposes, so no

rik: it does kind of describe the same thing

dbaron: but in Filters it does enable a background that's not used for  
rendering purposes

alex: it still just implies creating a buffer

  … whether it's used as the input to a filter, fine, that's irrelevant

  … but draw into an offscreen is all it says

  … in CSS it would be draw into an offscreen, and then composite it

  [some discussion about how enable-background is like opacity:0.999,  
meaning it just creates an offscreen]

dbaron: I'm not convinced that's compatible with how enable-background is  
used with Filters

alex: it is

  … you're thinking about the specific wording in Filters that requires an  
enable-background:new somewhere up the tree

  … BackgroundImage in Filters requires that

  … but general blending/compositing here doesn't require that

dirk: my question was just whether this can references Filters

rik: for just the background generation? yes

  … but we need to define the model here

tab: the text for enable-background is identical as for isolation

rik: yes

  … so maybe we should combine them, conceptually people might think of  
them the same

  … there might be some interesting effects by having them separate though

  … to me enable-background I don't even think about buffers

vhardy: I think it's confusing that for blending operations and  
compositing you can look at different background

  … for an author it's not trivial

  … but if there are good use cases

  … you might want to blend with more background than your alpha  
compositing, but I don't have a good example

rik: I can think of some

  … normally for isolation you want to do that on the blend mode

vhardy: I much prefer the "isolation" term than enable background

  … so maybe call it blend-isolation and composite-isolation or something

tab: I see there's just one word difference in the two property definitions

vhardy: they're the same but for different purposes

tab: can I volunteer to try to explain this more easily, because it is  
difficult to understand as written

rik: if you read the PDF reference, or the SVG Compositing spec, it only  
makes sense if you already understand it

steve: you want something like your informal explanation of flex box

vhardy: the section of background calculation should help

tab: but a higher level description would be good

  … I'll suggest some text for that

vhardy: you might like to look at the current wording on isolation groups  
and backdrop, since there's more layman wording there

liam: one of the things people always want to do, when you give them  
blending/compositing modes, is how do I write my own?

  … you might want to do this in JS

rik: you could do it in shaders

  … we already have filter effects

  … the problem we're running in to there is the security issues

vhardy: with shaders, with the current security measures, you don't get  
access to the colours of the textures

  … you could implement your own blend mode, but you couldn't do blend  
modes of the content with the backdrop

  … in my experience, in graphics APIs which have it, I haven't seen lots  
of uses of it

liam: the only people who want to write their own are researchers, or  
advanced programmers, but once one is written people want to use it

vhardy: we could later on add new built-in blend modes as we find people  
wanting them

jet: are you exposing that? color matrix?

alex: no

vhardy: with colour matrix, you could do that in shaders

  … for safe shaders, you can produce a color matrix from the shader  
operation

dbaron: SVG has this

vhardy: but it's uniform over the image

  … here you could do it per pixel

erik: are you waiting for more edits before publication?

nikos: more comments

vhardy: it'd be good to have a FPWD once we capture the issues

  … I think the sooner we get wider review the better

erik: so all of the features are in the draft now?

rik: the once that we want, yes

  … we need to work on the wording, but the spirit is there

florian: this is going to be good for people on low bandwidth phones

  … since big images don't need to be downloaded

dbaron: I think it would be useful for some bits to be clearer

florian: before publishing?

  … it would be nice if people could understand it before looking at it

nikos: I think it needs a bit more clarifying work on the model

rik: it is hard to make it easy

  … it's easy to use, but to write down the model is quite complex

tab: we need to ensure it's readable for authors too

rik: I don't want it so hard to read that it can't be implemented

vhardy: I think we need to have a balanace between perfection and earlier  
publication

tab: I'm happy with the spec as it's turning out, not yet as a WD

  … some of these properties don't have descriptions yet

  … I don't know if you could implement the spec as written right now

glazou: but it's not the first time we'd have a non-implementable FPWD

dbaron: I don't think the spec is understandable without asking a dozen  
questions of the authors

  … and I don't think we should publish before these clarifications

nikos: I wouldn't be comfortable publishing yet

steve: there are lots of things that can't be implemented by just reading  
the property definitions

rik: there is more elsewhere in the spec

tab: but right now you have no idea just from the property definition

  … I think we can just ask for publishing in a week or two once we add  
some clarifications

  … some informal descriptions that still give you an idea of what's  
happening

  … do you think waiting until these clarifications could be made will slow  
down implementation?

vhardy: no, but I'm not worried about that

  … there's been a lot of work done to explain the concepts and how to use  
the features

  … and I think it's useful to get feedback on that part

tab: for the blending modes, that's understandable

  … for the other half of the draft, those you can't get feedback on right  
now

  … they're not sufficiently understandable to get feedback on

  … the grouping stuff

nikos: I will work on that with Rik
Filter effects

vhardy: this is an update on the security aspects of shaders

  <ed> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html

  <ed> http://lists.w3.org/Archives/Public/public-fx/2012AprJun/0102.html

vhardy: as a reminder, the issue with shaders is that like with WebGL, you  
can make a shader that looks at pixel inputs, take a varying amount of  
time depending on the pixel input, and by observing the time the shader  
takes work out the content

  … we were able to demonstrate that with css shaders

  … there have been many options described

  … one we looked at that might be promising is static analysis of shaders

  … look at the compiler graph, find all texture access, taint the code  
graph

  … if there's any branching based on a colour, decide that the shader was  
insecure

  … we implemented this, worked well

  <ed>  
http://www.w3.org/Graphics/fx/wiki/CSS_Shaders_Security#Proposed_Method:_disallow_access_to_rendered_content_and_combine_with_blending

  … but we found that something we couldn't protect against is that  
branching itself is just one thing you can do

  … some arithmetic operations can trivially take different time depending  
on a pixel value

  … NaNs and infinities take different computation time

  … our latest finding was that we could demonstrate this problem on some  
architectures

  … the latest proposal we've made is to cut the problem at the root

  … which is the access to the rendered content

  … it's problematic for 2 reasons

  … it could be 3rd party content, could be addressed with CORS

  … but user information can turn up in any content, :visited links

  … it's a whack-a-mole problem

  … there are dictionary squiggly lines, if you render a text field, you  
can figure out what's in the dictionary of the user

  … so the current proposal is to remove texture access completely

  … we had some questions on how useful are shaders if you don't have this  
access

  … I wanted to show you demos under these limitations

  … the first one is a greyscale effect

  … the way this is done is by doing some shader writing, similar approach  
to when analysing shaders

  … we take a shader that is not full GLSL, instead of generating  
gl_frag_color, we have several conventions

  … if the shader generates a color matrix, the implementation then  
combines it with the original texture

  … the writer of the shader has no access to the input

  … so we say that the fragment shader combines the original image in  
multiple ways

  … another example is a vertex shader, just a vanilla one

  … this is still possible with the restrictions

  … [demo of folded paper effect]

  … there's shading applied in the folds of the image

  … the shader is interesting

  … it computes two things

  … the gl_Position, the distortion of the surface

  … and it also generates a shadow parameter

  … the fragment shader takes the shadow

  … you here you generate a blend colour that is combined by the  
implementation, not the shader

  … we just do multiplies in our prototype, but we could imagine more  
flexibility here

  … but already this provides some useful features

  … all the examples we created originally, we can do with the security  
restrictions

  … with a different formulation of the shaders

  … so that's our proposal to put in the spec

  … for the shader part, you just don't get texture access

  … and then move the spec to FPWD

  … which we already resolved to do, but held off due to this security issue

tab: that's awesome that all the existing examples can still be done  
around the restriction

  … this should make the picking easier?

vhardy: I don't think it changes picking much

tab: no you're right, doesn't make it easier

vhardy: the question is, we'd like to move ahead, we need to make the  
edits to the spec and then propose it for publication

  … our plan is to bring it up as soon as we have the draft ready and ask  
the group to publish FPWD
Test the Web Forward

vhardy: we've been working on an event in SF for a hackathon, learn how to  
write tests for SVG and CSS

  … learn how the test suites work, how to file bugs with browsers

  … the first part will be education for people

  … the second part will be to do test hacking for bugs they know, care  
about

  … and set them up for review

  … hopefully we'll get enough participation from people involved to do  
review during the event and after

  … so that there are positive contributions to the test suites

alan: Friday 15th and Saturday 16th of June

fantasai: can we make this an official FXTF event?

  … the main benefit is that then the main MS guys can come

vhardy: I think they're already coming

sylvaing: I think it'll be fine

vhardy: we're not trying to tout this as Adobe doing this, we're trying to  
make it a community event

fantasai: having Adobe be sponsors of the FXTF event would be fine

  … so I'd rather it be a W3C event

vhardy: the goal for us is to have it be a community event

fantasai: this doesn't affect logistics, just that we're agreeing to do  
this as a group -- it's just a naming thing

vhardy: the name "Test the Web Forward"...

fantasai: that's fine

  … but if we can have this be on our list of official meetings

vhardy: the other thing is, if anyone wants to join, especially if you're  
familiar with the test suite, that'll be useful

  … to help people out on all aspects of test development

  … version control, test review or just general CSS questions

hober: that's the weekend just after WWDC

vhardy: our hope is that some people from WWDC will stay for the event

  … logistically it'll be in the Adobe office in SF

heycam: how much focus is there on SVG here?

vhardy: we need some help there from SVG people

erik: are you looking for people to write tests, QA staff?

vhardy: we're looking for people to help developers at the event write  
tests

  … we'll have our test writers there at the event to help

erik: I think it would be good to hae some SVG people there

vhardy: Dirk will be there

alan: Dirk and Rebecca have been working on SVG tests, but the more people  
with test writing experience the better

heycam: how many non-browser people are you expecting there?

vhardy: not sure

  … if developer people don't turn up, the test helpers can write tests of  
course

alan: our goal is to get 100 people to show up

  … not sure how close to the goal we'll get

erik: so to make it an FX event, we're not having a TF meeting, just the  
tests

vhardy: it'll go from Friday mid-afternoon to Saturday night

heycam: hopefully we have our Sheperd set up by then

dirk: if not, then we can do it at the meeting

RESOLUTION: The FXTF will have a test hackathon in SF, June 15/16

  <scribe> ACTION: Erik to find out who from SVG WG will attend the FXTF  
hackathon [recorded in http://www.w3.org/2012/05/09-fx-irc]

  <trackbot> Created ACTION-75 - Find out who from SVG WG will attend the  
FXTF hackathon [on Erik Dahlström - due 2012-05-16].
SVG attributes becoming properties

  <ed> http://lists.w3.org/Archives/Public/www-style/2012Feb/0333.html

erik: the SVG WG is waiting for feedback from the CSS WG on the proposal  
to promote some SVG attributes to properties

  … this mail has a list of issues that we're waiting for answers on

  … let's go through the issues

  … the first is that CSS has existing properties for CSS boxes,  
top/left/width/height and SVG has x/y/width/height, at least on <rect>

  … it might be confusing to use different properties

  … the proposal here is to preserve the current SVG property names

  … so x, y, cx, cy (for circle) and not rename them

tab: we definitely don't want to rename to top/left, since they go along  
with right/bottom

  … and various SVG properties don't refer to the center, like cx/cy

  … I'm not that happy about x and cx be different properties

  … I would consider it a design mistake to be different names in SVG in  
the first place

  … but cx would apply to only two elements ever

  … and that's just kind of nasty

  … x and y being the positioning attributes for SVG is fine, but having  
some extra properties in there that only work for certain types of  
elements is just weird

dirk: you can say the same for x and y

  … they apply to only some elements

florian: do you want to use x and y to position everything in SVG?

tab: yes, but I think it's just x/y/cx/cy

erik: fx/fy?

tab: that does something different, so that's ok

erik: the proposal has the list of elements
  ... x1, x2, y1, y2 for <line>

hober: as a random author coming across a style sheet, with no indication  
they're SVG properties, it's weird

  … short meaningless names

  … I'd rather prefix them with "svg-"

fantasai: at least expanding them out to something more obvious

tab: we already have a bunch of properties that aren't prefixed

  … in general we don't want to prefix

  … for example maybe the positioning ones, just prefix

hober: so maybe come up with a prefix for SVG layout

fantasai: another issue is these are all studlyCaps

  … we use dashes in between words

fantasai: this is going to be inconsistent, some values with dashes some  
without

tab: we could alias

  … none of the existing properties use camel case, they're all dashed names

heycam: it's just the property values that are camel case

  … the flip side is that it could be confusing for authors to switch from  
camelCase to dashed-case

  … when they want to use the properties now

dirk: for the prefixed property names, what rules do we have?

fantasai: I think it just needs to be a longer name

dirk: for the presentation attributes currently they have the exact same  
name as properties

  … it would be confusing if it's not the case any more

hober: the prefix is a compromise in this case

  … there's an obvious mapping

fantasai: either way you'll want a table of some kind

  … one of the things about the CSS names is that we try to make the names  
make sense out of context

  … and that is absolutely not the case with "x2"

  … that's something that bothers me here

dirk: I'd like to see which ones you think aren't understandable enough

fantasai: anything three letters or less

hober: and several that are longer

dbaron: radius-x would be the minimum for rx

fantasai: radius could be shorthand for radius-x radius-y

hober: you'll need to have a table

  … I think using a prefix is a good compromise

  … but it doesn't make it readable for those who know svg, but at least  
it's flagged

fantasai: I would prefer to make the names more like CSS

heycam: were the other proposals acceptable?

jen: I think yes, for the most part

  … the key here is the functionality

  … obviously we'd prefer the proposal we have initially, but whatever  
makes sense between the two WGs is what we can move ahead with

fantasai: also we have some SVG properties that migrate into applying to  
all of CSS, for that reason I would prefer not to go with the svg- approach

  … and try tyo align them

  [some discussion about top/left vs x/y and bottom/right]

  <scribe> ACTION: Cameron to propose new CSS-friendly names for SVG  
attributes promoted to properties [recorded in  
http://www.w3.org/2012/05/09-fx-irc]

  <trackbot> Created ACTION-76 - Propose new CSS-friendly names for SVG  
attributes promoted to properties [on Cameron McCormack - due 2012-05-16].

  <ed> -- lunch break --

  <ed> Agenda:  
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Hamburg_2012/Agenda

  <fantasai> Scribe: fantasai

ed: issue of having different notations, e.g. scientific notation
  ... also question of units -- SVG units are optional
  ... proposal is to keep parsing of presentational attributes the same

fantasai: I agree with not changing how SVG parses its own syntax, but  
wouldn't want SVG rules to be used in CSS

  brief exchange on scientific notation in CSS

howcome: It's not scientific notation, it's a weird ascii notation

RESOLUTION: SVG parses its stuff the way it parses its stuff

  (obviously)

  Tab wants to later discuss scientific notation in CSS

  <glazou> it's a CSS pixel dammit !

krit: If CSS allows additional units, do we want to extend SVG to accept  
those?

fantasai: SVG properties and attributes both?

krit: yes

Bert: So we (CSS) can indirectly change the definition of SVG?
  ... Not sure that's a good idea...

krit: All CSS units should be supported in SVG, regardless of whether the  
viewer support CSS
  ... Just if you write content with the new units, it won't work in older  
SVG clients

Tab: Market pressure will cause SVG viewers to support all the units.

Bert: That's not really standardization...
  ... Shouldn't rely on a product to define the specification.
  ... Tab is saying you don't need a spec, just do what the browsers do.

Florian: If it has to be implemented, you might want to mention it anyway

ed: third issue, certain things that used to be content in SVG are now  
styleable
  ... e.g. width/height
  ... proposed resolution is to just accept that
  ... implication is that you no longer have to put them in the content

  ?: Will it be valid not to specify width/height on an element thenkrit

krit: They'll default to zero

Bert: this is to define animations. Do you have an SVG syntax for  
animations as well?

krit: This is for defining animations of presentation attributes in CSS

ed: It needs to be worked out how the initial values are set up

fantasai: Would a <rect> without width/height be invalid?

ed: it's not invalid today, just doesn't render
  ... think we need to work out the issues more exactly

Tab: yeah, you have to specify what width/height: auto means for  
rectangles. Should resolve to zero.

Bert: Are you expecting that the values that don't make sense are valid?  
Or do you want to say it's invalid?
  ... It happens to have a meaning when applied to CSS typography, but

vhardy: That would require discussion

  <scribe> ACTION: SVGWG to make proposal more concrete [recorded in  
http://www.w3.org/2012/05/09-fx-irc]

  <trackbot> Sorry, couldn't find user - SVGWG

ed: ... list that MS came up with,
  ... reasonably simple list of attributes
  ... s/.../list of attributes being "upgraded" to properties/
  ... list could be made longer, or just accept this as a starting point

Tab: I'm down with that

ed: issue of SVG and CSS properties that have different syntax
  ... That has to be dealt with somehow

dbaron: Sounds like they're different CSS properties

Tab: e.g. make text properties start with text-
  ... Happen to share a name in SVG, but are actually different attributes

Bert: ...
  ... if you have a UA that does both SVG and CSS, how do you know whether  
it applies or not?
  ... I'm not sure there's a solution for that, but sounds like you're  
trying to merge things together that might be too different to merge

krit: Just parsing rules that are different between attribute and  
property, e.g. scientific notation

Bert: In CSS if it doesn't parse right, you ignore it.
  ... you can't parse differently depending on whether it applies to an SVG  
element or not

krit: We already have this problem with e.g. font-size
  ... In SVG, you can put unitless values, but in CSS property you have to  
put units

  krit explains to Bert how this works

Bert: If I write font-size: 7;, it's ignored
  ... Unless I do it in SVG, then it works.

krit: If you transition from 7 to 18px, it works
  ... The CSS parser doesn't allow bare numbers.

fantasai: SVG can include font-size as either a CSS property (e.g. via  
style attribute) or SVG attribute. In CSS syntax, CSS parsing rules apply.  
In SVG attribute values, SVG parsing rules apply.

ed: issue 7 solved by issue 5
  ... last one is about the list of attributes to promote
  ... We're fine with the list as proposed

  Topic done.

  Switching over to CSS chairs
Agenda

  Sylvain proposes Grid for 4pm tomorrow

  Going to discuss transitions/animations/transforms now
Transitions

plinss: What's the status?

dbaron: Transitions is waiting on someone to write up proposals for the  
hard issues
  ... Went through most issues already. There were 4 issues that I  
categorized as hard
  ... which meant I need to think about them more before writing a  
proposal. Or someone else does.

Florian: So not a case of competing proposals, just don't have a propsoal

  dbaron; right

Florian: Any other issues?

dbaron: Not that should prevent LC, a few minor bits

  <sylvaing>  
https://www.w3.org/Bugs/Public/buglist.cgi?quicksearch=component%3ATransitions+whiteboard%3A%5Bhard%5D

dbaron: It's a pretty small number

sylvaing: I think there's 4 in bugzilla, here's the link

fantasai: Sounds like next action is to assign action items to people to  
write proposals

  [wecanhaztechnicalproblems

  ]

dbaron: actually, there are some here with multiple proposals
  ... Problem with 14608 is that there's no spec text

  "Interpolating transforms: a proposal to avoid Euler angles in favor of  
using quaternions"

dbaron: 14615 ...
  ... There's issue text in the spec that might be clearer...

  <dbaron> http://dev.w3.org/csswg/css3-transitions/#reversing

dbaron: Question of what we want to do when you reverse a transition  
that's midway through
  ... basic problem is, you say something like
  ... p {transition: margin-left 1s; }
  ... p:hover { margin-left: 100px; }
  ... paragraph supposed to move over 1s 100px
  ... Problem is if you move mouse out of paragraph 1/2 second in
  ... don't want it to move back to where it was in .25s
  ... not move at 1/4 the speed it moved in
  ... gets more complicated with varying timing functions

Florian: current implementations take 1s to go back?

dbaron: Gecko never took 1s to took back. It implements my proposal,  
proposal in the issue
  ... Dean proposed text above the issue, don't know if it was implemented
  ... So, what the proposal in spec text says is,
  ... That you detect that you're doing the opposite of what you just did
  ... You detect that you're now transitioning to the value you were  
transitioning from

  :)

dbaron: In that case, where you hit the reversing, you follow the exact  
reversing of what you've already done
  ... That means essentially that you use the specified timing function  
backwards
  ... Which means you're ignoring a specified timing function that's  
different for both directions

birtles: ease-in vs. ease-out

dbaron: You run only the piece of the function that you've already done.
  ... This can create discontinuities.
  ... If you move the mouse out at 99% completion, you do the reverse  
animation
  ... if you move the mouse out at 100% completion, you run the forward  
animation in the other direction
  ... What I implemented in Gecko, which I believe predates this text, was  
different
  ... We use the timing function that's specified, but we shorten the time  
of the transition
  ... based on how far it is, I believe, distance-wise, through its  
transition
  ... if you interrupt the transition 25% timewise and 50% distancewise,
  ... we run the transition as normal in the other direction, but multiply  
the duration at 50%
  ... when I was doing this, I experimented with various possibilities
  ... This was the only one that didn't look awful
  ... One of these emails does say what things I experimented with

glazou: What do you mean by ugly?

dbaron: It just looked wrong to me?
  ... I was doing animations of movement.
  ... In a similar way to what Webkit does right now, going back slowly,  
feels wrong
  ... the other experiments felt wrong

Florian: Other than the discontinuity, does the other proposal look wrong?

dbaron: The discontinuity is probably the biggest problem with it
  ... Could also be wrong if you're expecting transition to ease at it's  
start
  ... if you reverse it while you're in the fast part
  ... I think I tried this... trying to remember
  ... But may when look better if it compacts the timing function to ease  
into the reverse direction

glazou: ...

  <dbaron> http://lists.w3.org/Archives/Public/www-style/2009Dec/0319.html

plinss: could have a different timing function in the other direction

  <dbaron> http://lists.w3.org/Archives/Public/www-style/2009Dec/0321.html

vhardy: in SVG animations, you would actually have the second animation  
that [accumulates] the second one
  ...
  ... In an equivalent situation, instead of killing the first animation in  
the first one, you accumulate both
  ... The first one runs its course, but the base value of the second  
animation [...]

dbaron: sounds like that doesn't really reverse immediately
  ... There's an aspect there of UI responsiveness
  ... Want the user to feel like their action has done something, so want  
it to go in the other direction immediately

Steve: Sounds like this discussion won't get very far without someone  
making demos

plinss: Thing to me that seems logical is neither of these

  <vhardy_> vhardy: in SVG animations, if you use a 'to' animation, the  
'new' animation combines with the previous one without interrupting it,  
which gives a smooth transition.

plinss: If you interrupt first animation, jump to inverse position in the  
second animation

Florian: Intuitively, I'd say what you'd want is what vhardy said, but  
agree that doesn't give you the UI responsiveness

Liam: If we find and agree on a sensible result, can the user override it?

Florian: New property for controlling interrupted transitions?

plinss: depends on what you're doing: some defauls will make sense, and  
some will not

florian: so do something that's reasonable default not too hard to  
implement, address other things later

plinss: Do we have enough info, or do we need demos?

Tab: Think we need demos

plinss: So let's action someone to do that

  <scribe> ACTION: Tab to make demos [recorded in  
http://www.w3.org/2012/05/09-fx-irc]

  <trackbot> Created ACTION-77 - Make demos [on Tab Atkins Jr. - due  
2012-05-16].

plinss: next issue
  ... previous issue

  <dbaron> tabatkins__, http://dbaron.org/css/timing-function-graphs has a  
function called bezier() that in turn returns a function

plinss: There seems to be a proposal there

dbaron: we also implemented something with quaternians
  ... is there spec text there?

krit: we have exactly this in Transforms

dbaron: yeah, this is a Transforms spec issue. Deferred to later today

plinss: third issues

  bug 14621

  <dbaron> http://lists.w3.org/Archives/Public/www-style/2011Apr/0172.html

dbaron: question is, what do you do about mismatched lengths
  ... What does webkit do here?
  ... For backgrounds, ...

plinss: what happens without a transition

  ?

dbaron: I implemented least common multiple interpolation of lists
  ... The idea is, for a list that implicitly repeats, if you have  
mismatched length lists,
  ... you find the least common multiple of list lengths
  ... your interpolation result is a list of that length
  ... For list types that repeat, that produces a smooth interpolation from  
one to the other

Tab: repeating gradients do the same thing

  <dbaron>  
http://dbaron.org/css/test/2009/transitions/stroke-dasharray-transition

dbaron: spec right now says they're not interpolable

fantasai: is that a problem for level 3?

plinss: there's other cases where we say it doesn't transition now, but  
may later

Tab: Might want to split cases into where there's good invisible defaults  
(e.g. bg images), but for others there aren't (e.g. gradient stops)

plinss: For this specific issue, proposal is, it does not transition, and  
we may change our minds in a future version

RESOLUTION: mismatched background lists don't transition, will revisit in  
L4

  bug 14723

  <dbaron> http://lists.w3.org/Archives/Public/www-style/2011Nov/0016.html

Tab: The rule is, you don't kick a transition off from a transition
  ... even though transition change sthe computed value
  ... But if you have a value that depends on another value, e.g. em units
  ... That also changes the computed value, don't say whether that kicks of  
transitions

dbaron: Proposed solution is, don't start an independent transition, but  
the transition of the thing that's animating causes the other thing to  
animate too
  ... we all agree on how it shold work, just need to define it
  ... I think we need a more general statement than what's there

  <tabatkins__> "If a value changes in any way as a result of a property  
which is itself transitioning, do not start an independent transition."

  "The value will, however, change along with the transitioning property."

  discussion of the implications of this

  <dbaron> dynamic change of font-size plus width: 10em

  <dbaron> compare:

  <dbaron> transition: font-size 2s, width 10s

  <dbaron> with:

  <dbaron> transition: width 10s

  <dbaron> the first would make width transition over 2s, the second over  
10s

  <vhardy_> Related to previous discussion, transition with interruption of  
a transition using animation accumulation behavior:  
http://vhardy.github.com/quick-tests/test-reverse-anim.html

fantasai: Why are we transitioning the width at 10s in dbaron's second  
case?
  ... the font size jumps. The width then slowly catches up??

dbaron: can't make sense of rune's example, maybe should do what fantasai  
says

Tab: Maybe trigger a transition when the *cascade* results in a different  
value, instead of triggering on computed value change

dbaron: That would make transitions very different

plinss: In this example (rune's), you'll get a smooth transition
  ... if they transition at different rates, they transition at different  
rates

dbaron: The problem with that is, if you have the short time value on  
width and the large one on font size

plinss: Shouldn't go backwards at any point

dbaron: So then you're not transitioning computed values, you're  
transitioning cascaded values

  <dbaron> transition: font-size 10s, width 2s

tab: in a case where you've a 10s font-size tarnsition, and a short width  
transition

  <dbaron> is the bad one

tab: You have to be smarter to get a sane result
  ... When you're computed the end state for the width, you have to notice  
that font-size is also transitioning
  ... you have to match up the font-size timeline
  ... with the width timeline

plinss: If you have two interdependent properties transitioning at the  
same time
  ... the end value of the short one has to be the partially-transitioned  
value of the long one
  ... that's what the author specified, so just do that

dbaron: This is a horrible effect

plinss: but they asked for it

dbaron: It's a huge amount of work to implement, is it really worth the  
effort for something that is slightly less horrible

plinss: If you're going to argue that people won't do it, then don't  
transition in this case

dbaron: It's hard to even detect this case

szilles: If I want to implement a magnify transition ...

dbaron: you probably just want to use transforms to that
  ... we're looking at something that would double the complexity of a  
transitions implementation
  ... to implement Peter's proposal

plinss: ok, let's back up
  ... rune's example, is anyone saying that this shouldn't transition from  
50px to 100px over 1

  s

plinss: So as long as the time is the same, start to end, it's one  
transition
  ... so we're agreeing on that

shane: timing function ...

dbaron: you're transitioning computed values, not cascaded values

shane: webkit doesn't do that right now

dbaron: You're transitioning in ems?

shane: oh, I'm using percentages here

dbaron: percentages are computed values; that's different

fantasai: so... if we *were* transitioning cascaded values, would that  
solve all these problems?

Tab: my text says that the font-size transition does not cause a separate  
transition, but rune's testcase explicitly changes the value of width
  ... If you look at the end value fo ryour width
  ...

dbaron: If you have a style change, you look at the before/after values ..

Tab: The changes don't have before/after ..

dbaron: Yeah, we don't define simultaneity

Tab: If you assume simultaneity...

dbaron: Transitions are pretty dodgy. They just happen to work.
  ... if people care about edge cases, they should use some other mechanism

fantasai: What would happen if we transitioned on cascaded values?

dbaron: would break content
  ... also we don't store cascaded values
  ... would double or triple mem storage for properties

szilles: so if I have a 5px font size, and say that my width is 15px to  
3ems, would that trigger a transition

  right now, no

dbaron: My proposal is to leave the spec unchanged

plinss: which means?

Tab: yeah, I guess that would increase the complexity

dbaron: It means you might get extra transitions in a bunch of cases

plinss: In Webkit right now you're getting the width transition, and then  
the font-size transition

dbaron: I don't think sequential is the right thing.
  ... I think both Gecko and Webkit do not match what the spec currently  
says
  ... I don't know why Gecko doesn't

  <Bert> (It's a pity that Steve's example doesn't transition, you would be  
able to give a value a little shake in response to a :hover if it did. But  
it seems an acceptable limitation.)

plinss: what does Gecko do?

dbaron: I think it's changing width at the end...
  ... I think it's computing the transition on width, assuming the prior  
font size
  ... I think this might've been intentional ...
  ... I think we compute each property's transition assuming a cerain set  
of value for the other properties

  dbaron investigates

szilles: Sounds like one possible interpretation of simultaneous  
transitions..
  ... I would prefer it be undefined until someone shows a use case where  
it would be useful

dbaron: oh! rune's testcase is not what I thought it was
  ... I know why Gecko behaves the way it does now
  ... So basically, I didn't quite implement literally what the spec says,
  ... you block the effect of an inherited transition on an element you're  
transitioning on
  ... but [...]
  ... but I do that for everything at once
  ... So Gecko would behave differently here if the width were on #outer
  ... Because the font-size is inherited, it's ignoring it because it's an  
animation on an inherited property
  ... It's transitioning the width from 50px to 100px
  ... And then it jumps at the end to 300px

plinss: you're not computing inheritance during the transition

dbaron: We're saying, we started a transition on font-size. Now need to  
figure out whether we need to start transitions on descendants
  ... Let's block the inheritance effect ..
  ... But we start the wrong transition for width as a result
  ... But it's not a bug I can fix in any remotely performant way
  ... Would need to redo style resolution through the whole subtree

Tab: I understand the jumpiness and how to explain it
  ... dbaron's way is well-defined and cheap

dbaron: But it does behave badly in this case

  dbaron And rune's testcase is a reasonable testcase

plinss: So options are a) leave undefined b) define something cheap c)  
define something hard and correct ?

dbaron: I think you could get rune's testcase to work by following the spec
  ... but would still be weird if you gave different times
  ... font-size 2s, width 10s

szilles: Unless someone comes up with a good use case for it, don't think  
you'd need it...
  ...

dbaron: Talking about keeping spec as it is
  ... Talks about skipping a transition if change is due to inheritance

  Tab thinks that's cool

  szilles is confused

szilles: If I start a transition whenver it changes, would I get multiple  
starts as I go through the higher-level change?
  ... I'm changing font-size on the outer, and for each change in font size  
I trigger a new transition in width. Don't I?

dbaron: No, b/c the other rule -- dynamic change caused by an animation  
does not cause an animation

Tab: thought that was what I said

dbaron: No, another rule. Applies to CSS animations and SMIL, etc.
  ...
  ... Some of this depends on your mental model
  ... Are you processing the transition on the parent before you compute on  
the children or not

szilles: ...

dbaron: future points in time not a problem

Florian: So if what the spec says is fine, but it takes the entire WG an  
hour to figure out what it says, does the spec need clarification?

dbaron: There's one problem, which is what Steve says,
  ... We put this text in the spec because nothing defines the model of  
doing style resolution.
  ... I think we do need to add text to the spec to say that  
implementations do start a resolution if there was a change inherited from  
an ancestor on a different property.

Tab: Think that was the case steve was trying to call out, actually

szilles: I'd be happy not allowing that case

dbaron: Problem is detecting that case.

szilles: You have to detect it anyway b/c you have to detect subsequent  
changes

plinss: So, do we have a conclusion?

dbaron: I can try to write proposed text.

Florian: So you go write that, and we decide whether we like it

  <scribe> ACTION: dbaron to write proposed text for this discussion  
[recorded in http://www.w3.org/2012/05/09-fx-irc]

  <trackbot> Created ACTION-78 - Write proposed text for this discussion  
[on David Baron - due 2012-05-16].

  discussion of transitioning in premultiplied space

RESOLUTION: transition colors in premultiplied space

issue: using floor for integer is inconsistent with SMIL and SVG

  <trackbot> Created ISSUE-6 - Using floor for integer is inconsistent with  
SMIL and SVG ; please complete additional details at  
http://www.w3.org/Graphics/fx/track/issues/6/edit .

ted: there was some reason for it being floor

  <birtles> definition from SMIL is: coerced-integer-value = Math.floor(  
interpolated-value + 0.5 )

  <birtles>  
http://www.w3.org/TR/SMIL/smil-profile.html#SMILProfileNS-animation-module

  minutes of previous discussion on this:  
http://lists.w3.org/Archives/Public/www-style/2012Mar/0655.html

  some discussion between shane and Bert on this

shane: Might make it feel like the transition hasn't kicked in

  proposed to make it round(), for consistency

RESOLUTION: copy SMIL's rounding of numbers to integers

  cubic-bezier

dbaron: We allow cubic-bezier with y values outside the allowed range
  ... which means the value can be outside the allowed range of the  
property; since we usually check for that at parse time
  ... proposal is to clamp within range, e.g. while width is pushed below  
zero, it's treated as zero

RESOLUTION: clamp out-of-range values due to cubic-bezier out-of-range y  
values

Tab: what's marker-offset

dbaron: was in CSS2.0 and maybe CSS3 Lists

Tab: Definitely not in CSS3 Lists

fantasai: don't think marker-offset should be in this list

dbaron: Could leave transform to the Transforms spec
  ... Don't think that spec has the Animatable lines

fantasai: background/border-radius/box-shadow are defined in  
css3-background already
  ... suggest having css3-fonts handle font-

dbaron: Ok, I will make sure they're all in the relevant modules

plinss: so not adding to this spec

fantasai: multi-col is in CR, do we add that here then?

plinss: add them, but add them at-risk
  ... until there's 2 implementations

RESOLUTION: add only multicol properties from issue 12 additions; at risk  
until 2 implementations known to exist

  (rest go intheir respective modules)

  <break duration=15m>

  <Bert> (Backgrounds and Borders already contains the Animatable line in  
the propdefs)

  <shanestephens> column-count, column-width, column-rule-color are all  
transition able properties in WebKit

  <arronei_> Does anyone have a link to the updated agenda? The one on the  
wiki doesn't have the topics divided up by day.

  <plinss> arronei_: today is transitions, transforms and animations,  
tomorrow we'll sort out the csswg agenda

  <plinss> (unless we finish all the outstanding issues before the end of  
the day)

  <arronei_> plinss: thanks wanted to make sure I didn't miss anything.

  <plinss> oh, you're missing something alright...

  <arronei_> plinss: yeah I know I wish I was there. or maybe I don't :)
Transforms

  bug 14715 - clarify interopolation of some transform functions

krit: some concerns on the list
  ... say that transforms of same type can be interpolated
  ... added new section for that
  ... I think this bug is closed
  ... left open in case someon thinks it's not fixed

  <dbaron> http://dev.w3.org/csswg/css3-transforms/#animation

  <sylvaing> http://dev.w3.org/csswg/css3-transforms/#animation

  krit explains what's in the spec

dbaron: there's 2 possible ways to animate a skew
  ... You could animate as angle or as shear

krit: animate as angle right now

dbaron: interpolation rules should be in terms of computed values
  ... And computed values convert <length>s to a common unit

fantasai: unit could be anything
  ... although return values in the DOM are required to be in px
  ... summary is, there's a new section in the spec. People should review  
the new section. Who is volunteering to review the new section?

Tab: I'll review

krit: New section about just supporting 2D part of transforms

  <krit> http://dev.w3.org/csswg/css3-transforms/##two-dimensional-subset

krit: wanted to have some kind of fallback for UAs that don't support 3D  
transformations
  ... This section defines the 2D subset and specifies what to do if you  
don't support 3D

dbaron: simplification of [...] for 2D cases is not that simple
  ... the interpolation code that's referenced there will produce a 3D  
component in some cases
  ... in any case where the ? produces a change in sign between origin and  
destination

  <florianr> This belongs in the previous topic, but column-count,  
column-width, column-rule-color are all transition able properties in  
Opera as well.

  <dbaron> http://dbaron.org/css/test/2010/transition-negative-determinant

krit: For Webkit, we try to flatten 4D transforms. This is done by ... all  
values
  ... agree it's not the best way
  ... Current spec says you don't support 3D functions at all

dbaron: 2D and 3D specs used to be different
  ... ... is wrong, because simplifying for 2D case is a nontrivial case
  ... So you should say explicitly what happens there
  ... b/c Webkit shipped for multiple years with a 2D case that was wrong

fantasai: take this to the mailing list?

krit: any volunteers to review?

fantasai: I think dbaron just volunteered :)

  bug 15605

dbaron: if no one in the room understands the issue, maybe ppl who do  
understand can work on it

krit: They have no disagreement, but not sure what they have is correct

dbaron: is this formulated as a question?

krit: in general, not really specified what happens when perspective gets  
zoomed

  Liam talks about what happens when you multiply an axis by zero, or  
something

Liam: If w is zero, then don't proceed.
  ... Your universe is collapsed
  ... either you don't render the thing, or it's an error

  deferred to the experts not here

  bug 15709

Ted: Aryeh was writing some test where the result in different  
implementations was the same modulo some amount of rounding
  ... It made him unhappy when the tests were passing where there was a  
difference of some amount
  ... don't think this is a Transforms issue

Tab: Should be out-of-scope for this spec
  ... don't know how to address it

  <dbaron> krit, btw, you should really change id="#two-dimensional-subset"  
to id="two-dimensional-subset" so there's not a ## in the URL

  :)

  next is 15871

  <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15871

  "opacity should not cause transform-style: preserve-3d to be ignored"

Tab: So in the normal case, where everything's flattened,
  ... If you have element with 2 children, one is z-translated above,  
another z-translated below

Bert: Why would you not want preserve-3d?

dbaron: expensive to assume you want it on everything
  ... so you tell the implementation what you want to preserve 3D on, and  
then we flatten everything else

Tab: Yes, you tell implementations when you want the expensive path
  ... you have to track a bunch of stuff, and that slows things down

Bert: It's trial/error to make it work

  <cabanier> Example of preserve-3d:  
http://www.webkit.org/blog-files/3d-transforms/transform-style.html

Ted: If you put preserve-3d on a user stylesheet and browsed the web, it  
would be pretty painful

  ?: It makes sense that opacity flattens things

Ted: Remaining disagreement is how to express this in the spec

  <cabanier> ? is me

plinss: so where are we at?

Ted: If no one here has an idea, we'll move on to next issue...

plinss: Do we have agreement that we want opacity to flatten it?

Ted: I really hope so

Bert: what does that mean?

Tab: So we don't flatten with opacity
  ... We inherit opacity into the children instead of doing group opacity,  
that's why it works

plinss: That's not what we want
  ... sounds like we want application of opacity flattens it
  ... What if we then add controls to do group opacity or not?

Tab: if you don't do group opacity, you don't need to flatten

RESOLUTION: Because opacity does group opacity, it flattens 3D transforms

fantasai: does this issue affect other stacking-context things?

Tab: should check whether we need to do this property-by-property basis,  
or whether e.g. all stacking contexts (and/not? pseudo-stacking contexts)

  Tab explains what preserve-3d means

  <scribe> ACTION: hober to review wording of flatting cases to make sure  
all are covered, and whether should be property-by-property or generic wrt  
Appendix E [recorded in http://www.w3.org/2012/05/09-fx-irc]

  <trackbot> Created ACTION-79 - Review wording of flatting cases to make  
sure all are covered, and whether should be property-by-property or  
generic wrt Appendix E [on Edward O'Connor - due 2012-05-16].

  <krit> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15937

krit: how do you specify units of other things that aren't lengths?

dbaron: They're unitless (syntactically), but they represent units, and  
you need to specify what those units are

Tab: If you specify they're inches, not px, then the result would be  
completely different.
  ... So you need to specify the units.

  <krit> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15960

krit: everyone on the mailing list agreed on using quaternians
  ... I suggest to do that, and to use code from Firefox

  <krit>  
http://www.euclideanspace.com/maths/geometry/rotations/conversions/matrixToQuaternion/

  <tabatkins__> hober: Are there significant behavior differences?

  <cabanier> gimbal lock definition:  
http://en.wikipedia.org/wiki/Gimbal_lock

  <tabatkins__> tabatkins__: Normally, no - they're quite close unless  
you're close to a gimbal lock, in which case quaternions are almost  
certainly what you want. Using Euler angles just makes your element fling  
around wildly in the middle of the transition.

  <krit> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16328

RESOLUTION: Use quaternions for rotation by translating Firefox's  
implementation to spec pseudo-code

  <krit> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16377

  hober proposes an action item to smfr to propose wording for the previous  
bug

krit: ...
  ... It's not really defined how the line should look like
  ... is it a point or infinite line

  <dbaron> something about non-scaling stroke

krit: ... stroke should be relative to coordinate space of parent

  ??

krit: imagine you have a rect
  ... and you apply a scale
  ... the border of the rect gets scaled as well
  ... scale(2) makes it twice as big
  ... there's a property that allows not scaling the stroke
  ... when the element is skewed to zero height, what do you draw

Ted: do any implementations do anything other than not render in this case?

fantasai: so if you scale to zero height, do you see the line segment?
  ... skew can make an infinite line, so not render?

Liam: This was a problem in PostScript, you'd get infinite lines that seem  
to come from no reason
  ... Better to vanish from the screen than to fill it
  ... With PostScript we ended up with miter-limit and stuff like that

krit: choice of ignore transform, or not render
  ... for SVG we not render

  proposal is that all singular 3D transforms don't render

szilles: easier for user to understand if they all disappear

  (fantasai can't understand why scaling a rectangle to zero-height makes  
its non-scaling strokes also disappear)

krit: Do we draw nonscaling stroke in singular matrix, or not render

Tab: I don't think it's a non-perspective stroke

  <Liam> (no good reason except that it's probably hard to describe the  
circumstances when a zero-height rectangle could or could not be rendered)

Tab:

vhardy: Talked about height of zero, height of zero makes it disappear

krit: If you have a <div> that's zero height?

fantasai: if it has a border, you see it

krit: ...

Tab: Perspective shouldn't have non-scaling stroke magic

vhardy: Which scale?
  ... 3D context can be anywhere
  ... How do you extract what scale factor to handle?

Tab: But this isn't an issue for transforms, it's for vector-effects to  
define

vhardy: It only shows up for 3D transforms
  ... You have a perspective in 3D, right
  ... Ideally, your geometry would be transformed in 3D and then you'd  
stroke that.
  ... That's different from 2D, where you can compute your geometry .. and  
then stroke like you want on the object
  ... It's very simply described
  ... Think of stroking as computing another shape
  ... You can either get your geometry and then transform it
  ... or transform the outline first, then compute the stroke outline
  ... libraries don't allow you to do that

fantasai: what if you created a library that did do that?

tabatkins__: Add a new feature, call it non-perspective stroke

vhardy: Either disable non-scaling stroke altogether on 3D transforms
  ... or specify how you'd extract the scaled parameters

tabatkins__: if you just translateZ it you change the size...
  ... let's turn it off in all cases

  Florian raises case of a transform matrix crossing zero, where it's a 2D  
transform for a fraction of a second

Tab: any 3D transform function anywhere in your parent chain disables  
non-scaling stroke

RESOLUTION: as Tab proposed

RESOLUTION: Don't render if the transform is singular

  <krit> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16885

Bert: A 90deg rotation in 3D is not a singular transform?

Tab: correct; it's an invertible matrix

krit: some issues in source code

Tab: turn all the comment issues into actual <p class=issue>, remove  
solved/old ones, and bug any new ones

  <smfr> i'm with Tab

  <smfr> those comments were never intended for WG discussion

  <smfr> editors can resolve or make issues as necessary

  <scribe> ACTION: smfr to sift through comments in transforms spec, turn  
into issues or delete as appropriate [recorded in  
http://www.w3.org/2012/05/09-fx-irc]

  <trackbot> Created ACTION-80 - Sift through comments in transforms spec,  
turn into issues or delete as appropriate [on Simon Fraser - due  
2012-05-16].
Animations

  <sylvaing> http://lists.w3.org/Archives/Public/www-style/2012May/0189.html

sylvaing: animation-direction property has two value sbeen around for  
awhile: normal | alternate

  er

sylvaing: Lea suggested adding reverse
  ... and then alternate-reverse
  ... Now that we have all these values, she has two proposals
  ... One was to change the syntax of this one, it would take
  ... animation-direction: normal | alternate || reverse
  ... wouldn't need to remember which is first
  ... next one she proposed is redefining the feature as a new property
  ... instead of thinking of it as direction of animation, think of which  
iterations are reversing

animation-reverse: none | all | even | odd

  confusion over 0-based or 1-based counting

Florian: I think even/odd is more confusing, not really helping  
usability-wise

sylvaing: Lots of websites using animation-direction

Tab: I would prefer if it was intuitive and ovious which was even and  
which was odd, but it's not.

  fantasai agrees with Florian and Tab

fantasai: I agree with Lea on the reorderable alternate-reverse syntax,  
though
  ... Would also suggest s/normal/forward/ which matches css3-marquee

dbaron: Another item in the shorthand uses forwards/backwards

  <vhardy_> vhardy: I like the animation-reverse proposal

sylvaing: are we saying no to animation-reverse?

dbaron: Yeah, because of even/odd problem

vhardy: Could we come up with better names for even/odd?

dbaron: maybe, but it's also an issue of this going into the shorthand
  ... for splitting alternate-reverse, I think it's more confusing for the  
shorthand
  ... prefer to keep as one keyword so you think of it as one thing

Tab: Could add reverse-alternate as well as alternate reverse

fantasai: nooooo
  ... Although I would prever reverse-alternate, since you're going in  
reverse, then alternating

  <dbaron> dbaron: I think most people use the shorthand rather than the  
longhand, and I think we should encourage that.

vhardy: ...

Tab: Spec's descriptions rely on 0-indexing

dbaron: that description is 1-based
  ... I write prose 1-based and code 0-based

Tab: Right, I read that wrong.

RESOLUTION: no change to animation-direction syntax

  <smfr> yay

  <smfr> to-and-fro, fro-and-to

  <sylvaing> http://lists.w3.org/Archives/Public/www-style/2011Nov/0133.html

sylvaing: so which properties do we snapshot, exactly?

  <dbaron> At least we won't end up with 'alternate' and 'etanretla'

fantasai: sounds like someone should come up with a proposal and post it  
to the mailing list

dbaron: I should probably talk to smfr, and we should figure out what we  
agree on and disagree on

sylvaing: could defer from L3

  <smfr> fantasai: on what topic?

dbaron: Don't have implementations on the current spec

  smfr, snapshotting properties

  <smfr> ah right

  smfr, see resolution in those minutes -- they're incomplete

dbaron: concerned about simultaneity
  ... prefer to snapshot as little as possible
  ... implementations coalesce a lot, and that can vary

vhardy: work that remains to be done...

dbaron: agreeing on exactly what to snapshot

  <smfr> i'm happy to finesse that

birtles: ok with things jumping?

  <smfr> not sure if we'd consider changing our prefixed behavior tho

  <scribe> ACTION: smfr to make a list of snapshotting properties for  
animations [recorded in http://www.w3.org/2012/05/09-fx-irc]

  <trackbot> Created ACTION-81 - Make a list of snapshotting properties for  
animations [on Simon Fraser - due 2012-05-16].

  <smfr> hey no fair!

  <scribe> ACTION: dbaron to Make a list of snapshotting properties for  
animations [recorded in http://www.w3.org/2012/05/09-fx-irc]

  <trackbot> Created ACTION-82 - Make a list of snapshotting properties for  
animations [on David Baron - due 2012-05-16].

  <scribe> ACTION: dbaron to talk with smfr about converging on snapshotted  
properties list [recorded in http://www.w3.org/2012/05/09-fx-irc]

  <trackbot> Created ACTION-83 - Talk with smfr about converging on  
snapshotted properties list [on David Baron - due 2012-05-16].

  <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14792

  <smfr> sylvaing: i don't really have an opinion

RESOLUTION: drop declaration, not @keyframes, for bug 14792

  <sylvaing> http://lists.w3.org/Archives/Public/www-style/2011Nov/0071.html

dbaron: hard to get transitions and animations at same time [...]
  ... if the animation starts changing the property immediately, because  
it's an animation-caused style change

Tab: delay?

dbaron: Delay would let transition start
  ... Transitions operate on computed values

Tab: If you fill backwards, you're delay, then what?

dbaron: Then it would not trigger a style change
  ... well....
  ... if there were some othe rsimultaneous change to the property, it would
  ... we'd transition on that, ignoring the animation

  <smfr> don't you people have beer to drink?

dbaron: seems to me the idea of transitions is you're taking a change that  
already happened
  ... and you're saying you want to transition between them
  ... it's almost on top of the cascade
  ... we'd start a transition, but that transition wouldn't win? but that  
seemed really weird
  ... that's why I put transitions at the top
  ... Transitions override animations in Gecko
  ... animations need to be lower, because they let you actually specify a  
value
  ... You want say, a user stylesheet that says !important, not to be  
overrideable by an animation

sylvaing: we put them at the override level at some point in our  
discussions
  ... but override level is still ...
  ... an animation running at the override level will still run over  
transition, right?

dbaron: not in Gecko

sylvaing: so transitions win, what happens to animation?

dbaron: then the animation will resume when the transition finishes

sylvaing: it resumes at that point in its timeline?

vhardy: might be an opportunity to define behavior for SVG animations

sylvaing: having transitions+animations running on the same thing, sounds  
like edge case

birtles: some discussion about priority of SVG and CSS animations, CSS wins

  <dbaron> Gecko's cascade is currently:

  <dbaron> // Cascading order:

  <dbaron> // [least important]

  <dbaron> // -. UA normal rules = Agent normal

  <dbaron> // -. User normal rules = User normal

  <dbaron> // -. Presentation hints = PresHint normal

  <dbaron> // -. Author normal rules = Document normal

  <dbaron> // -. Override normal rules = Override normal

  <dbaron> // -. Author !important rules = Document !important

  <dbaron> // -. Override !important rules = Override !important

  <dbaron> // -. animation rules = Animation normal

  <dbaron> // -. User !important rules = User !important

  <dbaron> // -. UA !important rules = Agent !important

  <dbaron> // -. transition rules = Transition normal

  <dbaron> // [most important]

  trying to figure out cases where they'd interact

Florian: button that pulsates, but when you hover over it it stops and  
goes back to its spot

sylvaing: we don't have that in L3

fantasai: if I have a property that's animating, and I hover over it and  
that changes to a different value, does it transition?
  ... or is the transition suppressed because it's animating?
  ... e.g. animating color between blue and green, on hover specify red

  various conversations...

dbaron: Would be interested in hearing what IE and Webkit do

krit: animations override transitions

dbaron: let me write a testcase here...

  <smfr> webkit hasn't implemented !important overriding animations; it's  
going to be hard for us to do that

  <smfr> once we do, maybe having transitions overriding animations would  
be easier

fantasai: So let's take my button example, suppose the base state is  
yellow, but it's in an animating state that varies between blue and green
  ... the hover state is red
  ... let's suppose a transition does get triggered, what colors does it go  
between?

Florian: whatever color it's at to red

  e.g. teal to red

fantasai: Makes sense, now suppose the end state is animated, e.g. between  
red and orange

  <krit> http://pastebin.com/BDfVLU4W

fantasai: what color do I transition to?

Florian: Whatever color it would be at when you finish the transition

fantasai: so I line up the timelines, say the transition is 2s, right now  
the color is teal so I start at teal
  ... and I find the color at 2s into the animation, say it's orange
  ... and animate between teal and orange
  ... That seems to make sense
  ... don't know how hard it would be to implement, but it makes sense.

  <dbaron> http://dbaron.org/css/test/2012/anim-and-trans

  Meeting closed.

  <kennyluck> tabatkins__, is there an agenda for the meeting today and  
tomorrow?

  <dbaron> http://wiki.csswg.org/planning/hamburg-2012 is what we have

  <dbaron> but I think the bulk of the agenda ordering is to be worked out  
tomorrow first thing

  <dbaron> (today was joint CSS/SVG)

  <kennyluck> dbaron, oh ok. Thank!
Summary of Action Items
[NEW] ACTION: Cameron to propose new CSS-friendly names for SVG attributes  
promoted to properties [recorded in http://www.w3.org/2012/05/09-fx-irc]
[NEW] ACTION: dbaron to Make a list of snapshotting properties for  
animations [recorded in http://www.w3.org/2012/05/09-fx-irc]
[NEW] ACTION: dbaron to talk with smfr about converging on snapshotted  
properties list [recorded in http://www.w3.org/2012/05/09-fx-irc]
[NEW] ACTION: dbaron to write proposed text for this discussion [recorded  
in http://www.w3.org/2012/05/09-fx-irc]
[NEW] ACTION: Erik to find out who from SVG WG will attend the FXTF  
hackathon [recorded in http://www.w3.org/2012/05/09-fx-irc]
[NEW] ACTION: hober to review wording of flatting cases to make sure all  
are covered, and whether should be property-by-property or generic wrt  
Appendix E [recorded in http://www.w3.org/2012/05/09-fx-irc]
[NEW] ACTION: smfr to make a list of snapshotting properties for  
animations [recorded in http://www.w3.org/2012/05/09-fx-irc]
[NEW] ACTION: smfr to sift through comments in transforms spec, turn into  
issues or delete as appropriate [recorded in  
http://www.w3.org/2012/05/09-fx-irc]
[NEW] ACTION: SVGWG to make proposal more concrete [recorded in  
http://www.w3.org/2012/05/09-fx-irc]
[NEW] ACTION: Tab to make demos [recorded in  
http://www.w3.org/2012/05/09-fx-irc]

  [End of minutes]
  Minutes formatted by David Booth's scribe.perl version 1.136 (CVS log)
  $Date: 2011-05-12 12:01:43 $

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