See also: IRC log
<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).
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.
<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
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
… 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
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].
<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
Sylvain proposes Grid for 4pm tomorrow
Going to discuss transitions/animations/transforms now
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
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 :)
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].
<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!