06:57:19 <RRSAgent> RRSAgent has joined #fx
06:57:20 <RRSAgent> logging to http://www.w3.org/2012/05/09-fx-irc
06:57:26 <tabatkins__> tabatkins__ has joined #fx
06:57:28 <ed> Zakim, this will be FXTF
06:57:28 <Zakim> I do not see a conference matching that name scheduled within the next hour, ed
06:57:44 <tabatkins__> I'll be a few minutes late - voice chatting with my wife.
06:58:24 <ed> Agenda: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Hamburg_2012/Agenda
07:00:08 <shanestephens> shanestephens has joined #fx
07:01:41 <arronei_> arronei_ has joined #fx
07:01:42 <birtles> birtles has joined #fx
07:04:38 <ed> Zakim, room for 8?
07:04:39 <Zakim> ok, ed; conference Team_(fx)07:04Z scheduled with code 26632 (CONF2) for 60 minutes until 0804Z
07:04:53 <krit> krit has joined #fx
07:04:59 <Zakim> Team_(fx)07:04Z has now started
07:05:07 <Zakim> + +49.403.063.68.aaaa
07:05:22 <ed> Topic: Transitions/Animations: New animation proposal
07:05:34 <ed> chair: ed
07:05:40 <birtles> http://people.mozilla.org/~bbirtles/web-animations/presentation/web-animations.html
07:07:31 <vhardy_> vhardy_ has joined #fx
07:08:02 <jet> jet has joined #fx
07:08:03 <vhardy_> ScribeNick: vhardy
07:08:04 <cabanier> cabanier has joined #fx
07:08:10 <vhardy_> Topic: Web Animation proposal
07:08:19 <Liam> Liam has joined #fx
07:08:22 <dbaron> http://people.mozilla.org/~bbirtles/web-animations/presentation/web-animations.html
07:09:01 <glenn> glenn has joined #fx
07:09:03 <vhardy_> brian: presenting the work done on Web Animation. Work done with Shane, Rik, Tab, Dmitry, Alex, Vincent.
07:09:10 <fantasai> fantasai has joined #fx
07:09:22 <vhardy_> brian: trying to focus the animation effort. What we are proposing is a script API that underlies both specs. 
07:09:34 <vhardy_> ... the CSS and SVG animations can be implemented in terms of that API.
07:09:55 <vhardy_> ... the API can be useful as is to script authors as well. 
07:10:13 <glazou> glazou has joined #fx
07:10:13 <vhardy_> ... we hope that as a result of this, there will be a single place to focus for animation efforts.
07:10:31 <vhardy_> brian: I want to reflect on the initial problem we are trying to solve.
07:11:18 <vhardy_> brian: going through the presentation at http://people.mozilla.org/~bbirtles/web-animations/presentation/web-animations.html
07:12:13 <vhardy_> brian: discussing limitations of SVG and CSS animation models.
07:12:42 <vhardy_> ... Proposing to have script extensible declarative animations.
07:13:50 <vhardy_> ... three specifications: the Web Animations API and two specs. explaining the mapping of SVG and CSS animations to that API.
07:14:29 <vhardy_> ... In the model, an animation 'template' can generate multiple animation instances for various targets.
07:15:30 <vhardy_> ... Another key concept is grouping of a series of animations. Lets you sync. different animations. Can have a parallel group and a sequential group.
07:15:39 <vhardy_> .... you can nest groups.
07:16:10 <vhardy_> .. Also have a notion of template on the AnimGroup (AnimGroup/AnimGroupInstance)
07:16:52 <vhardy_> ... Model that underlies the proposal: Timing Model and Animation Model.
07:17:13 <vhardy_> ... there is a hierarchy of timelines.
07:17:37 <vhardy_> ... the nice thing is that you can use the same timing on a group or an animation.
07:18:14 <vhardy_> ... the timing model has a start time and a start delay. This allows support of the SVG timing model and more intuitive models.
07:19:03 <vhardy_> glenn: can you have negative start time and negative start delay?
07:19:15 <vhardy_> brian: yes. This is compatible with what is done in CSS.
07:19:42 <dbaron> (I think he said you can have a negative delay, but a negative start time doesn't make as much sense.)
07:19:46 <shanestephens> vhardy_:  brian's response was "yes for negative start delay, but negative start time isn't useful"
07:22:40 <vhardy_> liam: is this about path morphing or motion animation?
07:22:51 <vhardy_> (several): motion animation (move along a path)
07:23:01 <vhardy_> jet: does the model define a sprite model?
07:23:03 <vhardy_> alex: no
07:23:39 <vhardy_> brian: there is a mapping between the CSS declarative animations and the objects.
07:24:38 <vhardy_> .... similarly for SVG. The SVGAnimationElement interface inherits from Anim (from this new API)
07:25:06 <vhardy_> .... some features are not included (such as sync. base timing).
07:25:25 <vhardy_> ... some features in the API are not in SVG yet and hopefully will be exposed in SVG 2.
07:26:08 <vhardy_> heycam: if you can declare an animation with sync. base but you can still interact with it, will that work?
07:26:26 <vhardy_> brian: you could have more APIs in the SVG specific subclasses that could expose the sync. base graph for example.
07:26:56 <vhardy_> brian: there is a link to the current draft that is work in progress. There is a pointer to the CSS integration draft.
07:27:00 <dbaron> http://people.mozilla.org/~bbirtles/web-animations/web-animations.html
07:27:08 <dbaron> http://people.mozilla.org/~bbirtles/web-animations/css-integration.html
07:27:10 <vhardy_> ... I would like to hear comment about the reaction to the approach.
07:27:33 <vhardy_> krit: I have questions about the limitations. I disagree with the limitations you listed for SVG.
07:27:49 <vhardy_> .... animations in SVG are re-usable. You can re-use them with <use> element.
07:28:09 <vhardy_> heycam: you can use the element, but not the <animation> element.
07:28:18 <vhardy_> krit: you can point to an animation from a <use>
07:28:53 <vhardy_> .... you can synchronize the start/end of animations.
07:29:16 <vhardy_> .... I would be interested in CSS transitions to sync. with the beginning and end of transitions.
07:29:57 <vhardy_> .... in CSS, the timing parameters do not change after the start of the animation/transition.
07:30:03 <vhardy_> brian: this is still in discussion I believe.
07:30:30 <vhardy_> ... 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.
07:30:59 <vhardy_> krit: about accumulation, it needs to be specified for each property type. e.g., transform. Where should the accumulation model should be defined?
07:31:19 <vhardy_> brian: I think it makes most sense in the relevant spec. (e.g., CSS transform for the transform property).
07:31:41 <vhardy_> krit:we are doing it for transform now, but I think it should be in the combined web animation spec.
07:31:53 <vhardy_> .... it should be in CSS transition as well.
07:32:13 <vhardy_> brian: I am not sure we can capture all the data types we will ever need.
07:32:51 <vhardy_> dbaron: it think we already agreed to add the animatable entry in all new properties and for existing properties, it can be in the animation spec.
07:33:26 <dbaron> s/animation spec/transitions spec/
07:33:49 <vhardy_> krit: the web animation also specifies the relation to CSS cascading?
07:33:51 <vhardy_> brian: yes.
07:34:04 <tabatkins__> tabatkins__ has joined #fx
07:34:21 <vhardy_> glazou: questions. Web authors already complain about the process for CSS animations and transitions. Will this delay these specs?
07:34:26 <vhardy_> brian: no.
07:34:31 <vhardy_> ... it will not have any impact.
07:34:33 <sylvaing> sylvaing has joined #fx
07:34:46 <vhardy_> dbaron: you mean this is something we are doing for the next level?
07:35:01 <vhardy_> brian: the CSS animations and transitions should not change as a result of these specs.
07:35:26 <vhardy_> dbaron: I would like to advance these specs as they are and then we incorporate in the next level of these specs.
07:35:57 <vhardy_> 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.
07:36:13 <vhardy_> glazou: do you think this is a ground layer or is it something new?
07:36:20 <vhardy_> which do you expect authors to use.
07:36:58 <vhardy_> 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.
07:37:08 <vhardy_> shane: all the CSS OM would still work.
07:37:29 <vhardy_> glazou: you would have multiple implementations on the market, some with the new API and some without.
07:37:52 <vhardy_> ... once this is in the wild, you'll have incompatible support in browsers.
07:38:07 <vhardy_> tab: this is laying the ground for a model and does not change the behavior of the current specs.
07:38:25 <vhardy_> glazou: given its simplicity, people will start using it, and browsers not implementing it will be left behind.
07:38:39 <vhardy_> sylvaing: how is this specific to this proposal compared to other proposals?
07:38:53 <vhardy_> glazou: animations are already used.
07:39:07 <vhardy_> szilles: is your point that the API could create confusing for authors?
07:39:21 <vhardy_> sylvaing: I think people will use the most interoperable.
07:39:35 <vhardy_> tab: this is just adding a new API to do animations in JS in addition to CSS.
07:39:56 <vhardy_> dbaron: it might actually help to call the part that integrates with CSS animations and transitions level 4.
07:40:38 <vhardy_> 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.
07:40:53 <vhardy_> (discussion on serialization).
07:41:07 <vhardy_> brian: .. this is something we have discussed but that is not in the spec. currently.
07:41:30 <vhardy_> ... if you manipulate CSS and/or SVG animations, these are still serializable after animation.
07:41:41 <vhardy_> s/animation/manipulation through API.
07:42:19 <vhardy_> tab: I am not sure we have to worry about people doing things in JS and serializing.
07:42:27 <vhardy_> glazou: I am thinking of editors.
07:42:37 <vhardy_> tab: it could be serialized to CSS.
07:42:49 <vhardy_> brian: I think this is a valid point, we need to look at serialization.
07:43:02 <vhardy_> shane: I think we could add support for serialization.
07:43:10 <vhardy_> brian: this is good feedback.
07:43:23 <vhardy_> florian: shane had made a presentation a few F2F meetings ago. Where is that?
07:43:40 <vhardy_> shane: much of the material I presented then, did not make it to the specification, but it could be added. 
07:43:54 <vhardy_> brian: we had a section in the spec, but decided to leave it out for the first iteration.
07:44:28 <vhardy_> vhardy: is there a shim for that?
07:44:41 <vhardy_> shane: I am working on it, it will be available.
07:44:49 <vhardy_> dbaron: there was a discussion about cascading?
07:44:49 <Zakim> +Tav
07:44:55 <Tav> zakim, mute tav
07:44:55 <Zakim> Tav should now be muted
07:45:21 <vhardy_> 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.
07:45:37 <vhardy_> ... what happens if they happen at the same time on the same property?
07:46:11 <vhardy_> shane: the answer there is that we have a model to address this. One replaces the other.
07:46:25 <vhardy_> krit: I think this is more complicated than that from the cascade point of view.
07:46:41 <vhardy_> dbaron: I think there is a good reason for css transitions to be on top because they operate on computed value.
07:46:57 <vhardy_> ... the fact they are on top usually won't show up because they do not react to computed value changes.
07:47:29 <vhardy_> krit: if there is an inline style specified on :hover, it would override the transition (on the same property)
07:47:45 <vhardy_> dbaron: no, it will not override the transition and I am pretty sure it is interoperable.
07:49:05 <vhardy_> 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.
07:49:18 <vhardy_> brian: for the case of SVG, this is what we are thinking of doing.
07:49:36 <vhardy_> ... there are some things that we are thinking could be added to CSS syntax as well.
07:50:04 <vhardy_> 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.
07:50:21 <vhardy_> brian: we have gone through that process, for example for groups.
07:50:31 <vhardy_> ... it could be worth going through this again.
07:51:29 <vhardy_> (discussion about where transitions fit into the cascade).
07:51:39 <vhardy_> dbaron: transitions only start when the computed value changes.
07:52:04 <vhardy_> ... if you have a rule that is so strong the computed value never changes, the transition never happens.
07:52:16 <vhardy_> ed: what is the next step?
07:52:25 <vhardy_> brian: is this something we should continue?
07:52:37 <cabanier> cabanier has left #fx
07:52:54 <vhardy_> 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.
07:53:09 <vhardy_> florian: I think considering how it can be done declaratively is not quite enough.
07:53:21 <vhardy_> .... people will ship the API before there is a declarative solution.
07:54:12 <vhardy_> .... 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.
07:56:31 <vhardy_> 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.
07:56:46 <vhardy_> ... I see more people using CSS animations than JQuery animations.
07:57:06 <vhardy_> tab: CSS animations were not designed for advanced animations. The JS api is designed for that. 
07:57:25 <vhardy_> ... the sort of things people are hacking css animations for today, we want to help with/correct.
07:57:40 <vhardy_> ... things are painful right now.
07:57:55 <vhardy_> ted: people are animate things declaratively and imperatively. 
07:58:12 <vhardy_> ... they'll do it both ways and it is good to rationalize the model. It seems like a win to me.
07:58:33 <vhardy_> glazou: may be we missed features in the current CSS animations/transitions specs.
07:58:58 <vhardy_> shane: we are in a good position to describe what is missing in the current spec.
07:59:20 <vhardy_> ... there is a mismatch between what some people want to do and the available features.
07:59:29 <vhardy_> glazou: the CSS wg never really worked on this problem.
07:59:49 <vhardy_> florian: working on the underlying model is good, but the focus should be on declarative markup before the API.
08:00:03 <vhardy_> glazou: what is the commitment of browser vendors on this work?
08:00:16 <vhardy_> ... what is the commitment?
08:00:38 <vhardy_> jet: if we are contemplating new animation functions v.s., this new model, we would do the new model first.
08:00:54 <vhardy_> glazou: so this is level 3 for you, not level 4?
08:01:07 <jdaggett> jdaggett has joined #fx
08:02:10 <vhardy_> (discussion about Mozilla's interest in the specification ...).
08:02:21 <vhardy_> dbaron: I would not draw a hard line here.
08:03:19 <vhardy_> vhardy: we will participate in the specification work with Dmitry Baranoskiy
08:03:35 <vhardy_> ed: I think it is early to commit, but this is interesting.
08:03:54 <vhardy_> florian: this is interesting, but I am not sure we would do it soon. It looks nice.
08:04:04 <vhardy_> sylvaing: this seems to go in the right direction.
08:04:22 <vhardy_> brian: can we continue working on this?
08:04:34 <vhardy_> glazou: can we have a JS library for this?
08:04:40 <vhardy_> shane: I am working on this.
08:06:16 <vhardy_> vhardy: there are current limitations with the CSS animations and synchronization.
08:06:30 <vhardy_> glazou: bert is the gatekeeper of CSS declarative support.
08:06:50 <vhardy_> ... this is the first time that we are saying that we are going to replace script by script.
08:07:01 <vhardy_> brian: this is not just the CSS wg, this is the FX task force.
08:07:33 <vhardy_> ... 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.
08:07:58 <vhardy_> glazou: I am not sure that declarative solutions have limitations. Eventually, we have always succeeded in the past.
08:08:07 <vhardy_> ... e..g, variables.
08:08:23 <vhardy_> ... eventually, the last proposal is well integrated in the spirit of CSS.
08:08:34 <vhardy_> florian: it is hard to find simple solutions.
08:08:52 <vhardy_> glazou: a declarative solution for animations, sync. is possible. Just hard to find.
08:09:31 <vhardy_> florian: I agree that only when you hit the limit of declarative markup, you get to script.
08:09:47 <Cyril> Cyril has joined #fx
08:10:03 <vhardy_> brian: event with the 10year long SMIL work, there are still cases where you need to resort to script.
08:10:13 <dbaron> s/event/even/
08:10:20 <vhardy_> ... we should make it so that the script API can be consistent with the declarative solution and integrates.
08:10:54 <vhardy_> florian: we can look at what people do with scripts, build the underlying model, expand the declarative syntax and then add an API.
08:11:09 <vhardy_> alex: the most important part of this spec. is the model we are trying to define. 
08:11:55 <vhardy_> ... 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.
08:12:21 <vhardy_> ... this is what we are trying to get right. Whether this is expressed as script or declarative, this is an orthogonal problem.
08:12:39 <vhardy_> glazou: I think we should formally answer brian's question.
08:13:14 <vhardy_> RESOLVED: The group accepts Web Animation as a work item.
08:14:12 <vhardy_> 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.
08:14:32 <vhardy_> florian: would the CSS part become part of CSS Animation Level 4?
08:14:45 <vhardy_> brian: this is up to the CSS wg. dbaron has suggested it.
08:14:57 <vhardy_> glazou: should we have a single document?
08:15:14 <vhardy_> .. you could start editors draft separately, but you could join them later.
08:15:18 <vhardy_> (several agree).
08:15:45 <Bert> Bert has joined #fx
08:15:47 <vhardy_> Topic: CSS Transform update
08:16:33 <vhardy_> krit: we had a discussion about the SVG part of CSS transform.
08:16:40 <vhardy_> .... here is the list of general CSS issues.
08:16:51 <ed> https://www.w3.org/Bugs/Public/buglist.cgi?product=CSS&component=Transforms&resolution=---
08:17:04 <ed> http://dev.w3.org/csswg/css3-transforms/
08:17:13 <AD> AD has joined #fx
08:17:14 <vhardy_> krit: for the 3D part, I am relying on the other editors. There is a problem with the perspective.
08:17:16 <birtles_> birtles_ has joined #fx
08:17:40 <vhardy_> ... 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.
08:18:11 <vhardy_> ... we re-wrote some parts like section 14 (The Transform Functions).
08:18:41 <vhardy_> ... the SVG and 2D issues can be addressed in the next two weeks. The 3D issues require more feedback from implementors.
08:18:49 <vhardy_> ed: do you want a resolution to publish?
08:19:02 <vhardy_> krit: yes. Many things have been updated. There are a few issues remaining.
08:19:11 <vhardy_> ed: everybody fine with publishing a new WD
08:19:31 <vhardy_> RESOLVED: The task force agrees to publish a new version of the CSS Transform specification draft.
08:19:43 <vhardy_> ed: break now.
08:19:47 <vhardy_> (15mn)
08:20:01 <Zakim> -Tav
08:25:02 <Zakim> disconnecting the lone participant, +49.403.063.68.aaaa, in Team_(fx)07:04Z
08:25:04 <Zakim> Team_(fx)07:04Z has ended
08:25:04 <Zakim> Attendees were +49.403.063.68.aaaa, Tav
08:37:39 <nikos_> nikos_ has joined #fx
08:38:53 <jen> jen has joined #fx
08:38:59 <heycam> ScribeNick: heycam
08:39:13 <ed> topic: CSS Compositing and blending
08:39:21 <ed> https://dvcs.w3.org/hg/FXTF/raw-file/tip/compositing/index.html
08:40:04 <heycam> rik: talking today about compositing and blending in css and canvas
08:40:12 <heycam> … nikos and I have been working on a spec to integrate this into the browser world
08:40:17 <heycam> … why do we want to add this to the web platform?
08:40:21 <heycam> … designers already use this
08:40:24 <heycam> … they want to use it in web tools
08:40:29 <heycam> … currently they must rasterise
08:40:36 <heycam> … so it'd be better to support this natively
08:40:41 <heycam> … another reason is that it is easy to describe in css
08:40:49 <heycam> … the math behind it is complex, but how you write it in CSS is simple
08:40:57 <heycam> … the third reason is that it's pretty easy for browser vendors to implement
08:41:07 <heycam> … looking at firefox/webkit, it's implemented in software
08:41:17 <heycam> … windows 8 exposes an api to do it natively
08:41:32 <heycam> … there was an SVG spec before, tailored towards SVG
08:41:38 <heycam> … we're trying to have a spec that just describes the model
08:41:46 <heycam> … it doesn't talk about in what world (SVG, CSS, …) it happens
08:41:50 <heycam> … it doesn't talk about buffers, just shapes
08:42:03 <heycam> … the previous spec used similar formulas for compositing and blending, which made them complex
08:42:06 <heycam> … so we pulled them apart
08:42:22 <heycam> … blending you can imagine as a painter mixing colours on a palette, and compositing is laying it down on a canvas
08:42:32 <heycam> … the second part of the spec is how it applies to CSS and SVG elements
08:42:39 <heycam> … thirdly, how this applies to the CSS box model
08:42:46 <heycam> … fourth, optionally, how this applies to canvas
08:42:55 <heycam> … there is already a globalCompositingOperator, so we're looking at extending that
08:43:06 <heycam> … the spec defines alpha compositing, describing how this works today
08:43:12 <heycam> … it talks about how the background is calucated, how to use group isolation
08:43:32 <heycam> … 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
08:43:44 <heycam> … you'd think this would be straightforward, but it causes some subtle side effects
08:43:57 <AD> AD has joined #fx
08:44:00 <heycam> … 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
08:44:07 <heycam> … another part the spec goes over is group alpha
08:44:20 <heycam> … which is described as applying the alpha to all elements in the group, without inheritance
08:44:29 <heycam> florian: is a group a set of elements matched by a selector?
08:44:35 <heycam> rik: no it's an element, like a <div> or a <g>
08:44:43 <heycam> dbaron: opacity is group opacity, that definition of "group"
08:44:58 <heycam> tab: what's an example of how lack of group invariance affects things?
08:46:07 <heycam> 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
08:46:20 <heycam> … the next section talks about porter-duff
08:46:27 <heycam> … this is primitive blending operations
08:46:33 <heycam> … firefox and webkit have this under the hood
08:46:36 <heycam> … and we want to expose it to the API
08:46:47 <heycam> … we go over all the porter-duff modes, we're not changing anything from their standard definitions
08:46:49 <krit> krit has joined #fx
08:46:51 <heycam> … we talk about how they work with groups
08:46:58 <heycam> … and what happens when you have porter-duff in an isolate group
08:47:03 <heycam> … we also discuss knockout behaviour
08:47:10 <heycam> … and clip-to-self
08:47:25 <heycam> … the next section, which is pretty much done, talks about blending
08:47:30 <heycam> … which is the PDF rendering model
08:47:36 <heycam> … it lists all the separatble and non-separable blending modes
08:47:46 <heycam> … the separable modes are ones that apply to the red, green, blue channels separately
08:47:53 <vhardy_> vhardy_ has joined #fx
08:47:59 <heycam> … non-separable ones convert to hsl, then performs the operation
08:48:07 <heycam> … the spec has some pictures indicating how these blending modes work
08:48:34 <heycam> … it also describes how blending interacts with groups and isolation
08:48:41 <heycam> … and again how knockout behaviour works
08:48:48 <heycam> … the next section is how you use this from css
08:49:03 <heycam> … we define a bunch of porter-duff css keywords for use in an 'alpha-compositing' property
08:49:18 <heycam> … (which are also used in canvas)
08:49:27 <heycam> … and the 'enable-background' property, which came from the SVG world
08:49:42 <heycam> … it might've been added to the filter shorthands?
08:49:47 <heycam> alex: no
08:49:50 <heycam> rik: [demos]
08:53:32 <heycam> [some discussion about clip-to-self, and how for css content clip-to-self will always be true]
08:53:43 <heycam> [as opposed to SVG content]
08:53:50 <heycam> rik: then we have the keywords for blending in CSS
08:54:02 <heycam> … we have a 'blend-mode' property, which has keywords normal, multiply, screen, ...
08:54:11 <heycam> … the 'isolation' property  auccumulate | isodlate
08:54:21 <heycam> … and 'knock-out' preserve | knock-out
08:55:02 <heycam> … [demo of blend modes with two photographs]
08:56:20 <heycam> … [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]
08:56:43 <heycam> dbaron: is there a group for the blending, or the alpha compositing?
08:56:50 <heycam> … there are lots of things in CSS where there's a composite drawing operations
08:56:53 <heycam> rik: for background images?
08:57:05 <heycam> dbaron: drawing borders it's not precisely defined if there's overlap, or two separate things that overlap
08:57:11 <heycam> rik: all of those things are considered part of the group
08:57:16 <heycam> dbaron: even with alpha-compositing?
08:57:17 <heycam> dbaron: yes
08:57:21 <heycam> s/dbaron/rik/
08:57:38 <heycam> rik: we're going to propose a keyword that lets you control things within the group
08:58:06 <heycam> … the section of the spec that talks about html, we should mention that any element is a group
08:58:17 <heycam> nikos: any discrete thing is a group
08:58:23 <heycam> dbaron: there's a separate group for the text and the shadow?
08:58:27 <heycam> rik: no, they're in the same group
08:58:37 <heycam> vhardy: the broders, background, shadow all form a graphical group
08:58:52 <heycam> dbaron: so this proposal doesn't involve change the rendering within a single element's parts?
08:58:57 <heycam> rik: yes but this keyword later can change this
08:59:08 <heycam> … designers have said they want this behaviour
08:59:21 <heycam> vhardy: having a different blend mode for the shadow and the element, for example
09:00:01 <heycam> rik: [demos an image blending with itself]
09:00:08 <heycam> … photoshop users often do this to beef up the contrast
09:01:40 <heycam> … [demos blended video]
09:01:58 <heycam> … now we come to how to do blending within a css box
09:02:03 <heycam> … this is a bit up in the air still
09:02:16 <heycam> … we're thinking of having a 'background-alpha-compositing' property, which gives you a list
09:02:28 <heycam> … list of porter duff operators, one for each background
09:02:37 <heycam> … 'background-blend-mode' for how they blend to each other
09:02:59 <heycam> … three other properties: 'box-shadow-blend-mode', 'text-shadow-blend-mode' and 'foreground-blend-mode'
09:03:05 <heycam> … I don't like that there are so many keywords
09:03:09 <heycam> … maybe they can be collapsed into one
09:04:01 <heycam> heycam: referencing the differnet parts of the css boxes is like what I wanted for the paint-order operator in SVG
09:04:11 <heycam> … but there I had the parts of the SVG element in the property value, but here you have them in the property name
09:04:15 <heycam> vhardy: it could be in the value here too
09:05:05 <heycam> dbaron: is foreground-blend-mode applying to all contents, or just some?
09:05:19 <heycam> … as in not within some other child element?
09:05:31 <heycam> … so if you had an inline element inside the p, it would or wouldn't apply?
09:05:32 <heycam> rik: it would apply
09:05:43 <heycam> dbaron: I actually prefer not separating the contents
09:06:08 <heycam> heycam: and the borders and backgrounds of the child elements are considered the contents of the original element?
09:06:09 <heycam> rik: yes
09:06:14 <heycam> … we haven't implemented these three properties yet
09:06:28 <heycam> … next we have keywords for adding blending to canvas
09:06:50 <heycam> … we can extend the list of porter-duff operators in globalCompositeMode
09:06:55 <heycam> … should it be separate?
09:07:06 <heycam> dbaron: I don't understand the separation between alpha compositing and blending mode
09:07:17 <heycam> rik: blending works on the colours, and then this result is alpha composited on the destination
09:07:25 <heycam> dbaron: both of these seem to be functions that have two inputs and one output
09:07:36 <heycam> alex: the difference is alpha compositing affects the alpha channel, blend modes only affect colour channels
09:07:52 <heycam> dbaron: the alpha compositing does affect the colour channels
09:07:59 <heycam> alex: but only in terms of how much it lightens
09:08:08 <heycam> … you're multiplying red * red, blue * blue, green * green
09:08:16 <heycam> … alpha compositing with opacity=1 is just the soure
09:08:21 <heycam> … as you drop alpha, it changes the colour
09:08:32 <heycam> … with a blend mode, even if completely opaque, it can affect the colours
09:08:38 <heycam> … when you apply alpha it's all done at the one time
09:08:41 <heycam> s/soure/source/
09:08:55 <heycam> rik: are you tripped up because you think you need to look at the background twice?
09:08:59 <heycam> tab: it's just that the math looks imilar
09:09:02 <heycam> s/imilar/similar/
09:09:08 <heycam> alex: alpha compositing is just blend mode with function=1
09:09:18 <heycam> vhardy: you don't have to implement them as separate steps, you can combine them
09:09:27 <heycam> … it's common mental model for designers to think about these things separately
09:09:37 <heycam> rik: and it makes things easier to describe
09:09:46 <heycam> … in the SVG spec it was complex because it treated them both at the same time
09:09:59 <heycam> … and you don't really have to specify the result in the spec
09:10:15 <heycam> vhardy: also often we expect people just to use blend modes, they're more likely to be used than porter duff
09:10:31 <heycam> tab: i doubt porter duff be that useful in css, more useful in svg
09:11:03 <heycam> rik: [demos example in firefox this time of canvas blend modes]
09:11:29 <heycam> … we have prototype implementations for webkit, chromium and firefox
09:11:32 <heycam> … in chromium we use the gpu
09:11:39 <heycam> … there are some issues in the current spec
09:11:51 <heycam> … you should read the spec first before we can have a conversation about them
09:12:02 <heycam> … right now, group isolation applies separately to blending and compositing
09:12:07 <heycam> … but that might make implementations more difficult
09:12:25 <heycam> … if you have isolation apply to both compositing and blending at the same time, it gets easier to calculate the background
09:12:33 <heycam> … which you'd need to do twice
09:12:37 <heycam> … the same applies to knock-out
09:12:48 <heycam> … also, there are too many keywords for blending/compositing inside the css box
09:13:05 <heycam> … if you just want to specify a blend mode on the text shadow, it should be concise
09:13:29 <heycam> … people also seem to be more in favour of having a separate property for blend modes
09:14:01 <heycam> … another question is should the spec be split, model from css/canvas details?
09:14:29 <heycam> … similar to the animations discussion this morning, it might be good to split it out
09:14:49 <heycam> florian: that would only be useful if you want the model to reach REC before the css syntax
09:15:03 <heycam> dirk: perhaps so you could use it just in canvas before css, too
09:15:11 <heycam> rik: I'm neutral on the splitting
09:15:16 <heycam> florian: I'd say don't split yet
09:15:27 <heycam> rik: we have working prototypes
09:15:51 <heycam> … for chromium we have hardware acceleration
09:16:00 <heycam> … in in webkit, it calls into Core Graphics
09:16:02 <heycam> s/in in/in/
09:16:24 <heycam> … in Firefox it uses Core Graphics on Mac, but on Windows we haven't done the Direct2D backend yet, so it uses software
09:16:30 <heycam> … we're pretty close to being able to publish a WD
09:16:37 <heycam> … the porter duff section needs to be clarified a bit
09:16:48 <heycam> dbaron: this has a three sentence definition of the enable-background property
09:17:01 <heycam> … which I remember being really complicated in SVG, and I think supporting it in CSS would require making it even more complicated
09:17:09 <heycam> … I think it's pretty close to working in CSS, but not quite
09:17:13 <heycam> rik: the keyword or the model?
09:17:20 <heycam> dbaron: I'm looking at the "The enable-background property" section
09:17:30 <heycam> … it should be described earlier in the spec how the background is calculated
09:17:35 <heycam> vhardy: there are more than three sentences
09:17:40 <heycam> nikos: in section 3
09:17:53 <heycam> dbaron: these sections should point to each other to some extent
09:18:07 <heycam> … the section just seems to be given examples, not a specification on how to do it
09:18:16 <heycam> rik: the background is basically everything that is rendered before
09:18:25 <heycam> dbaron: that doesn't explain what happens if you're in a group and the background is outside the group
09:18:31 <heycam> … that's the bit in SVG that has very complicated rules
09:18:38 <heycam> alex: you're talking about accumulate with porter-duff?
09:18:42 <heycam> dbaron: there's the set of rules for SVG filters
09:18:46 <heycam> rik: it's the same rules
09:19:04 <heycam> … 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"
09:19:11 <heycam> dbaron: CSS isn't so precise about "before" and "after"
09:19:21 <heycam> rik: in Firefox you compose a group and then composite it
09:19:32 <heycam> dbaron: but that's when there is a group, this blending happens on top of things which aren't in the group
09:19:42 <heycam> rik: enable-background creates a new stacking context
09:19:46 <heycam> … that's something that's not there today
09:19:53 <heycam> … everything browsers do currently is accumulate
09:20:04 <heycam> … the background calculation will take some time to do
09:20:19 <heycam> … in the group you have blending, you have two half rendered graphics, which you source over, then composite to the background
09:20:32 <heycam> 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
09:20:44 <heycam> … and the rules in SVG don't quite work when you have something that is both a container and draws stuff
09:20:50 <heycam> tab: SVG definitely does make that distinction
09:20:55 <heycam> dbaron: the wording of those rules would need to be updated
09:21:01 <heycam> … they'll need to be a bit more complex than what's in SVG
09:21:06 <heycam> … it's been a while since I've looked at it
09:21:14 <heycam> alex: you're tlkaing about the filter input that's BackgroundImage
09:21:17 <heycam> … that's only to do with SVG Filters
09:21:29 <heycam> … if you explicitly use that keyword, you need to ensure there's a background store somewhere up the chain
09:21:40 <heycam> … so you have to put an enable-background:new somewhere up the tree
09:21:44 <heycam> … but blending doesn't require that
09:21:53 <heycam> … so in effect it's always enable-background:accumulate in CSS/HTML
09:22:08 <heycam> dbaron: how does compositin on top of what's underneath work if you're inside a group?
09:22:19 <heycam> rik: you render the group first, then that group is blended/composited with what's behind
09:22:25 <heycam> dbaron: the blending happens only with what's in the group?
09:22:32 <heycam> rik: it applies to the rastered parts of the group
09:22:38 <heycam> alex: blending is different from filters
09:22:44 <heycam> dbaron: so why is enable-background in the draft?
09:22:48 <heycam> rik: in case you want to create a new stacking context
09:22:59 <heycam> … in a PDF with artwork you might not want that to interact with other things in the page
09:23:07 <heycam> dbaron: give it a stacking context or its own group?
09:23:16 <heycam> alex: stacking context is the wrong term
09:23:30 <heycam> … it's a new rendering surface
09:23:36 <heycam> dirk: so you draw the group into a new bitmap
09:23:40 <heycam> dbaron: it's like a new group
09:24:01 <heycam> rik: if you have a rectangle inside a group with enable-background:new, it will not multiply with content outside of it
09:24:08 <heycam> dbaron: so enable-background:new forces creation of a new group
09:24:17 <heycam> … it's essentially like saying opacity:0.9999
09:24:18 <heycam> alex: yes
09:24:25 <heycam> dbaron: except it also has this effect on SVG Filters
09:24:38 <heycam> alex: the complication for SVG Filters is that some of the primitives require a backing store, so you need this enable-background somewhere
09:24:43 <heycam> … but that's orthogonal to this
09:25:16 <heycam> 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
09:25:51 <heycam> … does alpha compositing apply to individual drawing operations or to the element as a group?
09:25:57 <heycam> alex: not sure what you mean
09:25:59 <heycam> nikos: both I think
09:26:07 <heycam> rik: if you specify it to the group, it applies to the group not its children
09:26:13 <heycam> dbaron: the alpha-compisitng property applies to all elements
09:26:28 <heycam> … src-over has this nice property that it's the way we draw everything normally
09:26:37 <heycam> … but once you pick another one of these values, it matters how it applies
09:26:41 <heycam> s/compisitng/compositing/
09:26:55 <heycam> … 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
09:27:08 <heycam> … or whether you're doing each of these drawing operations with the porter duff mode
09:27:12 <heycam> … is blend mode the same way?
09:27:15 <heycam> alex: yes
09:27:27 <heycam> dirk: Filters also defines enable-background, should it share the definition somehow?
09:27:47 <heycam> rik: the one in the Filters spec talks about buffers...
09:27:59 <heycam> dbaron: there's nothing in apart from this section that references enable-background?
09:28:08 <heycam> … if I search for enable-background in this spec, it's only in 6.2.2 The enable-background property
09:28:13 <heycam> … which has just three sentences
09:28:17 <heycam> rik: that needs to be fixed
09:28:25 <heycam> nikos: in general there's not enough description of groups and how that interacts
09:28:31 <heycam> alex: or even of what enable-background does
09:28:44 <heycam> rik: that's why I said the section on Porter Duff needs to be expanded
09:28:48 <heycam> … since it doesn't talk about groups
09:28:57 <heycam> alex: but enable-background doesn't actually talk about what it does
09:29:05 <heycam> rik: so it needs to reference the model, and the model needs to be updated
09:29:12 <heycam> dirk: can it reference Filters?
09:29:19 <heycam> alex: they're for different purposes, so no
09:29:38 <heycam> rik: it does kind of describe the same thing
09:29:53 <heycam> dbaron: but in Filters it does enable a background that's not used for rendering purposes
09:29:58 <heycam> alex: it still just implies creating a buffer
09:30:07 <heycam> … whether it's used as the input to a filter, fine, that's irrelevant
09:30:12 <heycam> … but draw into an offscreen is all it says
09:30:19 <heycam> … in CSS it would be draw into an offscreen, and then composite it
09:31:06 <heycam> [some discussion about how enable-background is like opacity:0.999, meaning it just creates an offscreen]
09:31:20 <heycam> dbaron: I'm not convinced that's compatible with how enable-background is used with Filters
09:31:21 <heycam> alex: it is
09:31:38 <heycam> … you're thinking about the specific wording in Filters that requires an enable-background:new somewhere up the tree
09:31:42 <heycam> … BackgroundImage in Filters requires that
09:31:50 <heycam> … but general blending/compositing here doesn't require that
09:32:01 <heycam> dirk: my question was just whether this can references Filters
09:32:07 <heycam> rik: for just the background generation? yes
09:32:11 <heycam> … but we need to define the model here
09:32:23 <heycam> tab: the text for enable-background is identical as for isolation
09:32:24 <heycam> rik: yes
09:32:38 <heycam> … so maybe we should combine them, conceptually people might think of them the same
09:32:48 <heycam> … there might be some interesting effects by having them separate though
09:33:02 <heycam> … to me enable-background I don't even think about buffers
09:33:35 <heycam> vhardy: I think it's confusing that for blending operations and compositing you can look at different background
09:33:38 <heycam> … for an author it's not trivial
09:33:44 <heycam> … but if there are good use cases
09:33:57 <heycam> … you might want to blend with more background than your alpha compositing, but I don't have a good example
09:33:59 <heycam> rik: I can think of some
09:34:07 <heycam> … normally for isolation you want to do that on the blend mode
09:34:16 <heycam> vhardy: I much prefer the "isolation" term than enable background
09:34:30 <heycam> … so maybe call it blend-isolation and composite-isolation or something
09:34:44 <heycam> tab: I see there's just one word difference in the two property definitions
09:34:53 <heycam> vhardy: they're the same but for different purposes
09:35:49 <heycam> tab: can I volunteer to try to explain this more easily, because it is difficult to understand as written
09:36:01 <heycam> rik: if you read the PDF reference, or the SVG Compositing spec, it only makes sense if you already understand it
09:36:14 <heycam> steve: you want something like your informal explanation of flex box
09:36:31 <heycam> vhardy: the section of background calculation should help
09:36:37 <heycam> tab: but a higher level description would be good
09:36:41 <heycam> … I'll suggest some text for that
09:36:55 <heycam> vhardy: you might like to look at the current wording on isolation groups and backdrop, since there's more layman wording there
09:37:21 <heycam> liam: one of the things people always want to do, when you give them blending/compositing modes, is how do I write my own?
09:37:29 <heycam> … you might want to do this in JS
09:37:32 <heycam> rik: you could do it in shaders
09:37:38 <heycam> … we already have filter effects
09:37:46 <heycam> … the problem we're running in to there is the security issues
09:38:00 <heycam> vhardy: with shaders, with the current security measures, you don't get access to the colours of the textures
09:38:12 <heycam> … you could implement your own blend mode, but you couldn't do blend modes of the content with the backdrop
09:38:25 <heycam> … in my experience, in graphics APIs which have it, I haven't seen lots of uses of it
09:38:48 <heycam> 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
09:39:00 <heycam> vhardy: we could later on add new built-in blend modes as we find people wanting them
09:39:08 <heycam> jet: are you exposing that? color matrix?
09:39:12 <heycam> alex: no
09:39:19 <heycam> vhardy: with colour matrix, you could do that in shaders
09:39:28 <heycam> … for safe shaders, you can produce a color matrix from the shader operation
09:39:34 <heycam> dbaron: SVG has this
09:39:38 <heycam> vhardy: but it's uniform over the image
09:39:43 <heycam> … here you could do it per pixel
09:40:01 <heycam> erik: are you waiting for more edits before publication?
09:40:03 <heycam> nikos: more comments
09:40:11 <heycam> vhardy: it'd be good to have a FPWD once we capture the issues
09:40:17 <heycam> … I think the sooner we get wider review the better
09:40:21 <heycam> erik: so all of the features are in the draft now?
09:40:27 <heycam> rik: the once that we ant, yes
09:40:30 <heycam> s/ant/want/
09:40:38 <heycam> … we need to work on the wording, but the spirit is there
09:40:53 <heycam> florian: this is going to be good for people on low bandwidth phones
09:41:01 <heycam> … since big images don't need to be downloaded
09:41:15 <heycam> dbaron: I think it would be useful for some bits to be clearer
09:41:20 <heycam> florian: before publishing?
09:41:27 <heycam> … it would be nice if people could understand it before looking at it
09:41:34 <heycam> nikos: I think it needs a bit more clarifying work on the model
09:41:40 <heycam> rik: it is hard to make it easy
09:41:59 <heycam> … it's easy to use, but to write down the model is quite complex
09:42:16 <heycam> tab: we need to ensure it's readable for authors too
09:42:23 <heycam> rik: I don't want it so hard to read that it can't be implemented
09:42:35 <heycam> vhardy: I think we need to have a balanace between perfection and earlier publication
09:42:52 <heycam> tab: I'm happy with the spec as it's turning out, not yet as a WD
09:42:58 <heycam> … some of these properties don't have descriptions yet
09:43:10 <heycam> … I don't know if you could implement the spec as written right now
09:43:29 <heycam> glazou: but it's not the first time we'd have a non-implementable FPWD
09:43:46 <heycam> dbaron: I don't think the spec is understandable without asking a dozen questions of the authors
09:43:53 <heycam> … and I don't think we should publish before these clarifications
09:44:01 <heycam> nikos: I wouldn't be comfortable publishing yet
09:44:12 <heycam> steve: there are lots of things that can't be implemented by just reading the property definitions
09:44:19 <heycam> rik: there is more elsewhere in the spec
09:44:25 <heycam> tab: but right now you have no idea just from the property definition
09:45:16 <heycam> … I think we can just ask for publishing in a week or two once we add some clarifications
09:45:26 <heycam> … some informal descriptions that still give you an idea of what's happening
09:46:29 <heycam> … do you think waiting until these clarifications could be made will slow down implementation?
09:46:35 <heycam> vhardy: no, but I'm not worried about that
09:46:43 <heycam> … there's been a lot of work done to explain the concepts and how to use the features
09:46:48 <heycam> … and I think it's useful to get feedback on that part
09:46:53 <heycam> tab: for the blending modes, that's understandable
09:47:01 <heycam> … for the other half of the draft, those you can't get feedback on right now
09:47:09 <heycam> … they're not sufficiently understandable to get feedback on
09:47:12 <heycam> … the grouping stuff
09:47:22 <heycam> nikos: I will work on that with Rik
09:48:14 <heycam> Topic: Filter effects
09:48:21 <heycam> vhardy: this is an update on the security aspects of shaders
09:48:25 <ed> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html
09:48:32 <ed> http://lists.w3.org/Archives/Public/public-fx/2012AprJun/0102.html
09:49:09 <heycam> 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
09:49:16 <heycam> … we were able to demonstrate that with css shaders
09:49:31 <heycam> … there have been many options described
09:49:43 <heycam> … one we looked at that might be promising is static analysis of shaders
09:49:55 <heycam> … look at the compiler graph, find all texture access, taint the code group
09:49:58 <heycam> s/group/graph/
09:50:09 <heycam> … if there's any branching based on a colour, decide that the shader was insecure
09:50:13 <heycam> … we implemented this, worked well
09:50:14 <ed> http://www.w3.org/Graphics/fx/wiki/CSS_Shaders_Security#Proposed_Method:_disallow_access_to_rendered_content_and_combine_with_blending
09:50:24 <heycam> … but we found that something we couldn't protect against is that branching itself is just one thing you can do
09:50:39 <heycam> … some arithmetic operations can trivially take different time depending on a pixel value
09:50:50 <heycam> … NaNs and infinities take different computation time
09:51:06 <heycam> … our latest finding was that we could demonstrate this problem on some architectures
09:51:19 <heycam> … the latest proposal we've made is to cut the problem at the root
09:51:25 <heycam> … which is the access to the rendered content
09:51:29 <heycam> … it's problematic for 2 reasons
09:51:34 <heycam> … it could be 3rd party content, could be addressed with CORS
09:51:45 <heycam> … but user information can turn up in any content, :visited links
09:51:49 <heycam> … it's a whack-a-mole problem
09:52:05 <heycam> … there are dictionary squiggly lines, if you render a text field, you can figure out what's in the dictionary of the user
09:52:14 <heycam> … so the current proposal is to remove texture access completely
09:52:23 <heycam> … we had some questions on how useful are shaders if you don't have this access
09:52:31 <heycam> … I wanted to show you demos under these limitations
09:52:44 <heycam> … the first one is a greyscale effect
09:53:06 <heycam> … the way this is done is by doing some shader writing, similar approach to when analysing shaders
09:53:21 <heycam> … we take a shader that is not full GLSL, instead of generating gl_frag_color, we have several conventions
09:53:55 <heycam> … if the shader generates a color matrix, the implementation then combines it with the original texture
09:54:06 <heycam> … the writer of the shader has no access to the input
09:54:56 <heycam> … so we say that the fragment shader combines the original image in multiple ways
09:55:11 <heycam> … another example is a vertex shader, just a vanilla one
09:55:25 <heycam> … this is still possible with the restrictions
09:55:34 <heycam> … [demo of folded paper effect]
09:55:39 <heycam> … there's shading applied in the folds of the image
09:55:52 <heycam> … the shader is interesting
09:56:00 <heycam> … it computes two things
09:56:10 <heycam> … the gl_Position, the distortion of the surface
09:56:18 <heycam> … and it also generates a shadow parameters
09:56:21 <heycam> s/parameters/parameter/
09:56:33 <heycam> … the fragment shader takes the shadow
09:56:46 <heycam> … you here you generate a blend colour that is combined by the implementation, not the shader
09:56:58 <heycam> … we just do multiplies in our prototype, but we could imagine more flexibility here
09:57:04 <heycam> … but already this provides some useful features
09:57:25 <heycam> … all the examples we created originally, we can do with the security restrictions
09:57:33 <heycam> … with a different formulation of the shaders
09:57:43 <heycam> … so that's our proposal to put in the spec
09:57:53 <heycam> … for the shader part, you just don't get texture access
09:57:58 <heycam> … and then move the spec to FPWD
09:58:08 <heycam> … which we already resolved to do, but held off due to this security issue
09:58:19 <heycam> tab: that's awesome that all the existing examples can still be done around the restriction
09:58:55 <heycam> … this should make the picking easier?
09:59:01 <heycam> vhardy: I don't think it changes picking much
09:59:07 <heycam> tab: no you're right, doesn't make it easier
09:59:47 <heycam> 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
09:59:58 <heycam> … our plan is to bring it up as soon as we have the draft ready and ask the group to publish FPWD
10:00:28 <heycam> Topic: Test the Web Forward
10:00:52 <heycam> vhardy: we've been working on an event in SF for a hackathon, learn how to write tests for SVG and CSS
10:00:58 <heycam> … learn how the test suites work, how to file bugs with browsers
10:01:04 <heycam> … the first part will be education for people
10:01:13 <heycam> … the second part will be to do test hacking for bugs they know, care about
10:01:17 <heycam> … and set them up for review
10:01:32 <heycam> … hopefully we'll get enough participation from people involved to do review during the event and after
10:01:39 <heycam> … so that there are positive contributions to the test suites
10:01:55 <heycam> alan: Friday 15th and Saturday 16th of June
10:02:16 <heycam> fantasai: can we make this an official FXTF event?
10:02:24 <heycam> … the main benefit is that then the main MS guys can come
10:02:32 <heycam> vhardy: I think they're already coming
10:02:35 <heycam> sylvaing: I think it'll be fine
10:03:01 <heycam> vhardy: we're not trying to tout this as Adobe doing this, we're trying to make it a community event
10:03:12 <heycam> fantasai: having Adobe be sponsors of the FXTF event would be fine
10:03:21 <heycam> … so I'd rather it be a W3C event
10:03:30 <heycam> vhardy: the goal for us is to have it be a community event
10:03:43 <heycam> fantasai: this doesn't affect logistics, just that we're agreeing to do this as a group -- it's just a naming thing
10:03:51 <heycam> vhardy: the name "Test the Web Forward"...
10:03:53 <heycam> fantasai: that's fine
10:04:01 <heycam> … but if we can have this be on our list of official meetings
10:04:25 <heycam> vhardy: the other thing is, if anyone wants to join, especially if you're familiar with the test suite, that'll be useful
10:04:36 <heycam> … to help people out on all aspects of test development
10:04:47 <heycam> … version control, test review or just general CSS questions
10:04:54 <heycam> hober: that's the weekend just after WWDC
10:05:12 <heycam> vhardy: our hope is that some people from WWDC will stay for the event
10:05:21 <heycam> … logistically it'll be in the Adobe office in SF
10:05:51 <heycam> heycam: how much focus is there on SVG here?
10:06:01 <heycam> vhardy: we need some help there from SVG people
10:06:09 <heycam> erik: are you looking for people to write tests, QA staff?
10:06:22 <heycam> vhardy: we're looking for people to help developers at the event write tests
10:06:36 <heycam> … we'll have our test writers there at the event to help
10:06:48 <heycam> erik: I think it would be good to hae some SVG people there
10:06:55 <heycam> vhardy: Dirk will be there
10:07:07 <heycam> alan: Dirk and Rebecca have been working on SVG tests, but the more people with test writing experience the better
10:07:18 <heycam> heycam: how many non-browser people are you expecting there?
10:07:31 <heycam> vhardy: not sure
10:07:40 <heycam> … if developer people don't turn up, the test helpers can write tests of course
10:07:45 <heycam> alan: our goal is to get 100 people to show up
10:07:49 <heycam> … not sure how close to the goal we'll get
10:08:05 <heycam> erik: so to make it an FX event, we're not having a TF meeting, just the tests
10:08:18 <heycam> vhardy: it'll go from Friday afternoon to Saturday night
10:08:25 <heycam> s/afternoon/mid-afternoon/
10:09:01 <Zakim> Zakim has left #fx
10:09:21 <heycam> heycam: hopefully we have our Sheperd set up by then
10:09:25 <heycam> dirk: if not, then we can do it at the meeting
10:10:13 <heycam> RESOLUTION: The FXTF will have a test hackathon in SF, June 15/16
10:10:33 <heycam> ACTION: Erik to find out who from SVG WG will attend the FXTF hackathon
10:10:33 <trackbot> Created ACTION-75 - Find out who from SVG WG will attend the FXTF hackathon [on Erik Dahlström - due 2012-05-16].
10:10:53 <heycam> Topic: SVG attributes becoming properties
10:10:55 <ed> http://lists.w3.org/Archives/Public/www-style/2012Feb/0333.html
10:10:56 <Zakim> Zakim has joined #fx
10:11:04 <heycam> Zakim, room for 5?
10:11:06 <Zakim> ok, heycam; conference Team_(fx)10:11Z scheduled with code 26632 (CONF2) for 60 minutes until 1111Z
10:11:53 <Zakim> Team_(fx)10:11Z has now started
10:12:01 <Zakim> + +49.403.063.68.aaaa
10:12:45 <Zakim> + +1.732.216.aabb
10:13:19 <cabanier> cabanier has joined #fx
10:13:39 <heycam> erik: the SVG WG is waiting for feedback from the CSS WG on the proposal to promote some SVG attributes to properties
10:13:48 <heycam> … this mail has a list of issues that we're waiting for answers on
10:14:16 <heycam> … let's go through the issues
10:14:35 <heycam> … 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>
10:14:39 <heycam> … it might be confusing to use different properties
10:14:56 <heycam> … the proposal here is to preserve the current SVG property names
10:15:03 <heycam> … so x, y, cx, cy (for circle) and not rename them
10:15:10 <heycam> tab: we definitely don't want to rename to top/left, since they go along with right/bottom
10:15:20 <heycam> … and various SVG properties don't refer to the center, like cx/cy
10:15:27 <heycam> … I'm not that happy about x and cx be different properties
10:15:44 <heycam> … I would consider it a design mistake to be different names in SVG in the first place
10:15:50 <heycam> … but cx would apply to only two elements ever
10:15:54 <heycam> … and that's just kind of nasty
10:16:15 <heycam> … 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
10:16:23 <heycam> dirk: you can say the same for x and y
10:16:26 <heycam> … they apply to only some elements
10:16:39 <heycam> florian: do you want to use x and y to position everything in SVG?
10:16:47 <heycam> tab: yes, but I think it's just x/y/cx/cy
10:16:50 <heycam> erik: fx/fy?
10:16:55 <heycam> tab: that does something different, so that's ok
10:17:01 <heycam> erik: the proposal has the list of elements
10:17:15 <heycam> erik: x1, x2, y1, y2 for <line>
10:17:29 <heycam> hober: as a random author coming across a style sheet, with no indication they're SVG properties, it's weird
10:17:33 <heycam> … short meaningless names
10:17:37 <heycam> … I'd rather prefix them with "svg-"
10:17:43 <heycam> fantasai: at least expanding them out to something more obvious
10:17:50 <heycam> tab: we already have a bunch of properties that aren't prefixed
10:17:56 <heycam> … in general we don't want to prefix
10:18:02 <heycam> … for example maybe the positioning ones, just prefix
10:18:09 <heycam> hober: so maybe come up with a prefix for SVG layout
10:18:22 <heycam> fantasai: another issue is these are all studlyCaps
10:18:28 <heycam> … we use dashes in between words
10:19:44 <heycam> fantasai: this is going to be inconsistent, some values with dashes some without
10:19:52 <heycam> tab: we could alias
10:20:44 <heycam> … none of the existing properties use camel case, they're all dashed names
10:20:52 <heycam> heycam: it's just the property values that are camel case
10:21:45 <heycam> … the flip side is that it could be confusing for authors to switch from camelCase to dashed-case
10:21:49 <heycam> … when they want to use the properties now
10:22:06 <heycam> dirk: for the prefixed property names, what rules do we have?
10:22:12 <heycam> fantasai: I think it just needs to be a longer name
10:22:25 <heycam> dirk: for the presentation attributes currently they have the exact same name as properties
10:22:29 <heycam> … it would be confusing if it's not the case any more
10:22:35 <heycam> hober: the prefix is a compromise in this case
10:22:37 <heycam> … there's an obvious mapping
10:22:43 <heycam> fantasai: either way you'll want a table of some kind
10:23:17 <heycam> … one of the things about the CSS names is that we try to make the names make sense out of context
10:23:24 <heycam> … and that is absolutely not the case with "x2"
10:23:30 <heycam> … that's something that bothers me here
10:23:51 <heycam> dirk: I'd like to see which ones you think aren't understandable enough
10:23:57 <heycam> fantasai: anything three letters or less
10:24:01 <heycam> hober: and several that are longer
10:24:10 <heycam> dbaron: radius-x would be the minimum for rx
10:24:59 <heycam> fantasai: radius could be shorthand for radius-x radius-y
10:25:41 <heycam> hober: you'll need to have a table
10:25:50 <heycam> … I think using a prefix is a good compromise
10:26:00 <heycam> … but it doesn't make it readable for those who know svg, but at least it's flagged
10:26:10 <heycam> fantasai: I would prefer to make the names more like CSS
10:27:21 <heycam> heycam: were the other proposals acceptable?
10:27:26 <heycam> jen: I think yes, for the most part
10:27:30 <heycam> … the key here is the functionality
10:27:51 <heycam> … obviously we'd prefer the proposal we have initially, but whatever makes sense between the two WGs is what we can move ahead with
10:28:35 <heycam> 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
10:28:40 <heycam> … and try tyo align them
10:29:05 <heycam> [some discussion about top/left vs x/y and bottom/right]
10:30:07 <heycam> ACTION: Cameron to propose new CSS-friendly names for SVG attributes promoted to properties
10:30:07 <trackbot> Created ACTION-76 - Propose new CSS-friendly names for SVG attributes promoted to properties [on Cameron McCormack - due 2012-05-16].
10:30:47 <ed> -- lunch break --
10:30:59 <Zakim> - +1.732.216.aabb
10:37:00 <glazou> glazou has joined #fx
10:38:45 <jet> jet has joined #fx
10:57:54 <tantek> tantek has joined #fx
10:59:01 <tantek> tantek has joined #fx
10:59:38 <tantek> tantek has joined #fx
11:06:07 <Cyril> Cyril has joined #fx
11:16:01 <Zakim> disconnecting the lone participant, +49.403.063.68.aaaa, in Team_(fx)10:11Z
11:16:04 <Zakim> Team_(fx)10:11Z has ended
11:16:04 <Zakim> Attendees were +49.403.063.68.aaaa, +1.732.216.aabb
11:17:18 <jen> jen has joined #fx
11:29:45 <jet> jet has joined #fx
11:31:59 <tabatkins__> tabatkins__ has joined #fx
11:32:49 <ed> Zakim, room for 5?
11:32:51 <Zakim> ok, ed; conference Team_(fx)11:32Z scheduled with code 26632 (CONF2) for 60 minutes until 1232Z
11:33:16 <glazou> glazou has joined #fx
11:34:04 <Zakim> Team_(fx)11:32Z has now started
11:34:12 <Zakim> + +49.403.063.68.aaaa
11:34:16 <AlexD> AlexD has joined #fx
11:35:03 <ed> Agenda: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Hamburg_2012/Agenda
11:35:07 <fantasai> Scribe: fantasai
11:35:53 <fantasai> ed: issue of having different notations, e.g. scientific notation
11:36:16 <fantasai> ed: also question of units -- SVG units are optional
11:36:25 <fantasai> ed: proposal is to keep parsing of presentational attributes the same
11:36:33 <vhardy_> vhardy_ has joined #fx
11:37:25 <fantasai> fantasai: I agree with not changing how SVG parses its own syntax, but wouldn't want SVG rules to be used in CSS
11:37:32 <ed> topic: SVG attributes becoming properties
11:38:02 <fantasai> brief exchange on scientific notation in CSS
11:38:13 <fantasai> howcome: It's not scientific notation, it's a weird ascii notation
11:39:08 <fantasai> RESOLVED: SVG parses its stuff the way it parses its stuff
11:39:15 <fantasai> (obviously)
11:39:28 <Zakim> +Tav
11:39:47 <Tav> zakim, mute tav
11:39:47 <Zakim> Tav should now be muted
11:40:00 <fantasai> Tab wants to later discuss scientific notation in CSS
11:40:32 <glazou> it's a CSS pixel dammit !
11:40:32 <fantasai> krit: If CSS allows additional units, do we want to extend SVG to accept those?
11:41:29 <fantasai> fantasai: SVG properties and attributes both?
11:41:32 <fantasai> krit: yes
11:41:44 <fantasai> Bert: So we (CSS) can indirectly change the definition of SVG?
11:41:56 <fantasai> Bert: Not sure that's a good idea...
11:42:57 <fantasai> krit: All CSS units should be supported in SVG, regardless of whether the viewer support SVG
11:43:07 <vhardy_> vhardy_ has joined #fx
11:43:40 <fantasai> krit: Just if you write content with the new units, it won't work in older SVG clients
11:43:43 <krit> s/support SVG/support CSS/
11:44:14 <fantasai> Tab: Market pressure will cause SVG viewers to support all the units.
11:44:27 <fantasai> Bert: That's not really standardization...
11:44:40 <fantasai> Bert: Shouldn't rely on a product to define the specification.
11:45:00 <fantasai> Bert: Tab is saying you don't need a spec, just do what the browsers do.
11:45:54 <fantasai> Florian: If it has to be implemented, you might want to mention it anyway
11:46:48 <Zakim> + +1.732.216.aabb
11:47:08 <fantasai> ed: third issue, certain things that used to be content in SVG are now styleable
11:47:11 <fantasai> ed: e.g. width/height
11:47:22 <fantasai> ed: proposed resolution is to just accept that
11:47:56 <fantasai> ed: implication is that you no longer have to put them in the content
11:48:39 <fantasai> ?: Will it be valid not to specify width/height on an element then?
11:48:55 <tabatkins__> s/?/krit/
11:49:02 <fantasai> krit: They'll default to zero
11:49:13 <vhardy_> vhardy_ has joined #fx
11:49:53 <fantasai> Bert: this is to define animations. Do you have an SVG syntax for animations as well?
11:50:13 <fantasai> krit: This is for defining animations of presentation attributes in CSS
11:50:21 <fantasai> ed: It needs to be worked out how the initial values are set up
11:51:05 <fantasai> fantasai: Would a <rect> without width/height be invalid?
11:51:12 <fantasai> ed: it's not invalid today, just doesn't render
11:51:49 <fantasai> ed: think we need to work out the issues more exactly
11:52:08 <fantasai> Tab: yeah, you have to specify what width/height: auto means for rectangles. Should resolve to zero.
11:52:30 <fantasai> Bert: Are you expecting that the values that don't make sense are valid? Or do you want to say it's invalid?
11:52:42 <fantasai> Bert: It happens to have a meaning when applied to CSS typography, but
11:52:50 <fantasai> vhardy: That would require discussion
11:54:13 <fantasai> ACTION SVGWG: make proposal more concrete
11:54:14 <trackbot> Sorry, couldn't find user - SVGWG
11:54:59 <fantasai> ed: ... list that MS came up with, 
11:55:05 <fantasai> ed: reasonably simple list of attributes
11:55:24 <fantasai> ed: s/.../list of attributes being "upgraded" to properties/
11:55:49 <fantasai> ed: list could be made longer, or just accept this as a starting point
11:55:56 <fantasai> Tab: I'm down with that
11:56:39 <fantasai> ed: issue of SVG and CSS properties that have different syntax
11:56:47 <fantasai> ed: That has to be dealt with somehow
11:56:54 <fantasai> dbaron: Sounds like they're different CSS properties
11:57:16 <fantasai> Tab: e.g. make text properties start with text-
11:57:40 <fantasai> Tab: Happen to share a name in SVG, but are actually different attributes
11:58:38 <fantasai> Bert: ... 
11:58:51 <fantasai> Bert: if you have a UA that does both SVG and CSS, how do you know whether it applies or not?
11:59:13 <fantasai> Bert: 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
11:59:29 <fantasai> krit: Just parsing rules that are different between attribute and property, e.g. scientific notation
11:59:42 <fantasai> Bert: In CSS if it doesn't parse right, you ignore it.
12:00:02 <fantasai> Bert: you can't parse differently depending on whether it applies to an SVG element or not
12:00:09 <fantasai> krit: We already have this problem with e.g. font-size
12:00:23 <fantasai> krit: In SVG, you can put unitless values, but in CSS property you have to put units
12:01:49 <fantasai> krit explains to Bert how this works
12:03:43 <fantasai> Bert: If I write font-size: 7;, it's ignored
12:03:53 <fantasai> Bert: Unless I do it in SVG, then it works.
12:04:09 <fantasai> krit: If you transition from 7 to 18px, it works
12:04:25 <fantasai> krit: The CSS parser doesn't allow bare numbers.
12:06:18 <fantasai> 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.
12:06:42 <fantasai> ed: issue 7 solved by issue 5
12:07:05 <fantasai> ed: last one is about the list of attributes to promote
12:07:22 <fantasai> ed: We're fine with the list as proposed
12:08:08 <fantasai> Topic done.
12:08:24 <fantasai> Switching over to CSS chairs
12:08:46 <fantasai> Topic: Agenda
12:08:57 <fantasai> Sylvain proposes Grid for 4pm tomorrow
12:09:04 <florianr> florianr has left #fx
12:09:35 <florianr> florianr has joined #fx
12:09:52 <fantasai> Going to discuss transitions/animations/transforms now
12:10:16 <fantasai> Topic: Transitions
12:10:22 <fantasai> plinss: What's the status?
12:10:31 <fantasai> dbaron: Transitions is waiting on someone to write up proposals for the hard issues
12:10:43 <fantasai> dbaron: Went through most issues already. There were 4 issues that I categorized as hard
12:11:00 <fantasai> dbaron: which meant I need to think about them more before writing a proposal. Or someone else does.
12:11:11 <fantasai> Florian: So not a case of competing proposals, just don't have a propsoal
12:11:13 <fantasai> dbaron; right
12:11:19 <fantasai> Florian: Any other issues?
12:11:33 <fantasai> dbaron: Not that should prevent LC, a few minor bits
12:11:36 <sylvaing> https://www.w3.org/Bugs/Public/buglist.cgi?quicksearch=component%3ATransitions+whiteboard%3A%5Bhard%5D
12:11:39 <fantasai> dbaron: It's a pretty small number
12:11:47 <fantasai> sylvaing: I think there's 4 in bugzilla, here's the link
12:12:17 <fantasai> fantasai: Sounds like next action is to assign action items to people to write proposals
12:12:43 <fantasai> [wecanhaztechnicalproblems
12:12:44 <fantasai> ]
12:14:57 <fantasai> dbaron: actually, there are some here with multiple proposals
12:15:15 <fantasai> dbaron: Problem with 14608 is that there's no spec text
12:15:30 <fantasai> "Interpolating transforms: a proposal to avoid Euler angles in favor of using quaternions"
12:15:49 <fantasai> dbaron: 14615 ...
12:15:57 <fantasai> dbaron: There's issue text in the spec that might be clearer...
12:16:03 <dbaron> http://dev.w3.org/csswg/css3-transitions/#reversing
12:16:31 <fantasai> dbaron: Question of what we want to do when you reverse a transition that's midway through
12:16:46 <fantasai> dbaron: basic problem is, you say something like
12:16:55 <fantasai> dbaron: p {transition: margin-left 1s; }
12:17:04 <fantasai> dbaron: p:hover { margin-left: 100px; }
12:17:11 <fantasai> dbaron: paragraph supposed to move over 1s 100px
12:17:24 <fantasai> dbaron: Problem is if you move mouse out of paragraph 1/2 second in
12:17:35 <fantasai> dbaron: don't want it to move back to where it was in .25s
12:17:42 <fantasai> dbaron: not move at 1/4 the speed it moved in
12:18:05 <fantasai> dbaron: gets more complicated with varying timing functions
12:18:13 <fantasai> Florian: current implementations take 1s to go back?
12:18:29 <fantasai> dbaron: Gecko never took 1s to took back. It implements my proposal, proposal in the issue
12:18:40 <fantasai> dbaron: Dean proposed text above the issue, don't know if it was implemented
12:19:00 <fantasai> dbaron: So, what the proposal in spec text says is,
12:19:08 <fantasai> dbaron: That you detect that you're doing the opposite of what you just did
12:19:32 <fantasai> dbaron: You detect that you're now transitioning to the value you were transitioning from
12:19:49 <fantasai> :)
12:20:05 <fantasai> dbaron: In that case, where you hit the reversing, you follow the exact reversing of what you've already done
12:20:15 <fantasai> dbaron: That means essentially that you use the specified timing function backwards
12:20:27 <fantasai> dbaron: Which means you're ignoring a specified timing function that's different for both directions
12:20:34 <fantasai> birtles: ease-in vs. ease-out
12:20:45 <fantasai> dbaron: You run only the piece of the function that you've already done.
12:20:51 <fantasai> dbaron: This can create discontinuities.
12:21:05 <fantasai> dbaron: If you move the mouse out at 99% completion, you do the reverse animation
12:21:20 <fantasai> dbaron: if you move the mouse out at 100% completion, you run the forward animation in the other direction
12:22:16 <fantasai> dbaron: What I implemented in Gecko, which I believe predates this text, was different
12:22:28 <fantasai> dbaron: We use the timing function that's specified, but we shorten the time of the transition
12:22:42 <fantasai> dbaron: based on how far it is, I believe, distance-wise, through its transition
12:22:54 <fantasai> dbaron: if you interrupt the transition 25% timewise and 50% distancewise,
12:23:14 <fantasai> dbaron: we run the transition as normal in the other direction, but multiply the duration at 50%
12:23:27 <fantasai> dbaron: when I was doing this, I experimented with various possibilities
12:23:34 <fantasai> dbaron: This was the only one that didn't look awful
12:24:15 <fantasai> dbaron: One of these emails does say what things I experimented with
12:24:26 <fantasai> glazou: What do you mean by ugly?
12:24:31 <fantasai> dbaron: It just looked wrong to me?
12:24:36 <fantasai> dbaron: I was doing animations of movement.
12:24:48 <fantasai> dbaron: In a similar way to what Webkit does right now, going back slowly, feels wrong
12:24:55 <fantasai> dbaron: the other experiments felt wrong
12:25:09 <fantasai> Florian: Other than the discontinuity, does the other proposal look wrong?
12:25:17 <fantasai> dbaron: The discontinuity is probably the biggest problem with it
12:25:30 <fantasai> dbaron: Could also be wrong if you're expecting transition to ease at it's start
12:25:41 <fantasai> dbaron: if you reverse it while you're in the fast part
12:25:46 <fantasai> dbaron: I think I tried this... trying to remember
12:26:07 <glenn> glenn has joined #fx
12:26:11 <fantasai> dbaron: But may when look better if it compacts the timing function to ease into the reverse direction
12:26:36 <fantasai> glazou: ...
12:26:39 <dbaron> http://lists.w3.org/Archives/Public/www-style/2009Dec/0319.html
12:26:46 <fantasai> plinss: could have a different timing function in the other direction
12:26:54 <dbaron> http://lists.w3.org/Archives/Public/www-style/2009Dec/0321.html
12:27:06 <fantasai> vhardy: in SVG animations, you would actually have the second animation that [accumulates] the second one
12:27:09 <fantasai> ...
12:27:53 <fantasai> vhardy: In an equivalent situation, instead of killing the first animation in the first one, you accumulate both
12:28:06 <fantasai> vhardy: The first one runs its course, but the base value of the second animation [...]
12:28:38 <fantasai> dbaron: sounds like that doesn't really reverse immediately
12:28:55 <fantasai> dbaron: There's an aspect there of UI responsiveness
12:29:13 <fantasai> dbaron: Want the user to feel like their action has done something, so want it to go in the other direction immediately
12:29:25 <fantasai> Steve: Sounds like this discussion won't get very far without someone making demos
12:29:35 <fantasai> plinss: Thing to me that seems logical is neither of these
12:29:38 <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.
12:30:19 <fantasai> plinss: If you interrupt first animation, jump to inverse position in the second animation
12:31:03 <fantasai> Florian: Intuitively, I'd say what you'd want is what vhardy said, but agree that doesn't give you the UI responsiveness
12:31:20 <fantasai> Liam: If we find and agree on a sensible result, can the user override it?
12:31:42 <fantasai> Florian: New property for controlling interrupted transitions?
12:32:32 <fantasai> plinss: depends on what you're doing: some defauls will make sense, and some will not
12:32:52 <fantasai> florian: so do something that's reasonable default not too hard to implement, address other things later
12:33:04 <fantasai> plinss: Do we have enough info, or do we need demos?
12:33:17 <fantasai> Tab: Think we need demos
12:33:25 <fantasai> plinss: So let's action someone to do that
12:33:47 <fantasai> ACTION Tab: make demos
12:33:47 <trackbot> Created ACTION-77 - Make demos [on Tab Atkins Jr. - due 2012-05-16].
12:34:25 <fantasai> plinss: next issue
12:34:38 <fantasai> plinss: previous issue
12:34:44 <dbaron> tabatkins__, http://dbaron.org/css/timing-function-graphs has a function called bezier() that in turn returns a function
12:34:52 <fantasai> plinss: There seems to be a proposal there
12:35:05 <fantasai> dbaron: we also implemented something with quaternians
12:35:10 <fantasai> dbaron: is there spec text there?
12:35:20 <fantasai> krit: we have exactly this in Transforms
12:35:42 <fantasai> dbaron: yeah, this is a Transforms spec issue. Deferred to later today
12:35:48 <fantasai> plinss: third issues
12:35:57 <fantasai> bug 14621
12:36:00 <dbaron> http://lists.w3.org/Archives/Public/www-style/2011Apr/0172.html
12:36:24 <fantasai> dbaron: question is, what do you do about mismatched lengths
12:37:00 <fantasai> dbaron: What does webkit do here?
12:37:26 <fantasai> dbaron: For backgrounds, ...
12:37:30 <fantasai> plinss: what happens without a transition
12:37:31 <fantasai> ?
12:37:49 <fantasai> dbaron: I implemented least common multiple interpolation of lists
12:38:04 <fantasai> dbaron: The idea is, for a list that implicitly repeats, if you have mismatched length lists,
12:38:14 <fantasai> dbaron: you find the least common multiple of list lengths
12:38:22 <fantasai> dbaron: your interpolation result is a list of that length
12:38:46 <fantasai> dbaron: For list types that repeat, that produces a smooth interpolation from one to the other
12:39:01 <fantasai> Tab: repeating gradients do the same thing
12:39:14 <dbaron> http://dbaron.org/css/test/2009/transitions/stroke-dasharray-transition
12:40:30 <fantasai> dbaron: spec right now says they're not interpolable
12:40:36 <Zakim> -Tav
12:41:08 <fantasai> fantasai: is that a problem for level 3?
12:41:45 <fantasai> plinss: there's other cases where we say it doesn't transition now, but may later
12:42:13 <fantasai> 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)
12:42:27 <fantasai> plinss: For this specific issue, proposal is, it does not transition, and we may change our minds in a future version
12:42:40 <fantasai> RESOLVED: mismatched background lists don't transition, will revisit in L4
12:42:46 <fantasai> bug 14723
12:42:47 <dbaron> http://lists.w3.org/Archives/Public/www-style/2011Nov/0016.html
12:43:24 <fantasai> Tab: The rule is, you don't kick a transition off from a transition
12:43:39 <fantasai> Tab: even though transition change sthe computed value
12:43:48 <fantasai> Tab: But if you have a value that depends on another value, e.g. em units
12:43:59 <fantasai> Tab: That also changes the computed value, don't say whether that kicks of transitions
12:44:35 <fantasai> 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
12:44:53 <fantasai> dbaron: we all agree on how it shold work, just need to define it
12:45:04 <fantasai> dbaron: I think we need a more general statement than what's there
12:45:54 <tabatkins__> "If a value changes in any way as a result of a property which is itself transitioning, do not start an independent transition."
12:47:24 <fantasai> "The value will, however, change along with the transitioning property."
12:47:59 <fantasai> discussion of the implications of this
12:48:38 <dbaron> dynamic change of font-size plus width: 10em
12:48:42 <dbaron> compare:
12:48:50 <dbaron> transition: font-size 2s, width 10s
12:48:52 <dbaron> with:
12:48:55 <dbaron> transition: width 10s
12:50:09 <dbaron> the first would make width transition over 2s, the second over 10s
12:51:36 <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
12:52:57 <fantasai> fantasai: Why are we transitioning the width at 10s in dbaron's second case?
12:53:18 <fantasai> fantasai: the font size jumps. The width then slowly catches up??
12:54:59 <fantasai> dbaron: can't make sense of rune's example, maybe should do what fantasai says
12:55:23 <fantasai> Tab: Maybe trigger a transition when the *cascade* results in a different value, instead of triggering on computed value change
12:56:00 <fantasai> dbaron: That would make transitions very different
12:58:02 <fantasai> plinss: In this example (rune's), you'll get a smooth transition
12:58:11 <fantasai> plinss: if they transition at different rates, they transition at different rates
12:58:38 <fantasai> dbaron: The problem with that is, if you have the short time value on width and the large one on font size
12:59:37 <fantasai> plinss: Shouldn't go backwards at any point
12:59:48 <fantasai> dbaron: So then you're not transitioning computed values, you're transitioning cascaded values
13:00:09 <dbaron> transition: font-size 10s, width 2s
13:00:09 <fantasai> tab: in a case where you've a 10s font-size tarnsition, and a short width transition
13:00:11 <dbaron> is the bad one
13:00:16 <fantasai> tab: You have to be smarter to get a sane result
13:00:29 <fantasai> tab: When you're computed the end state for the width, you have to notice that font-size is also transitioning
13:00:38 <fantasai> tab: you have to match up the font-size timeline
13:00:46 <fantasai> tab: with the width timeline
13:01:07 <fantasai> plinss: If you have two interdependent properties transitioning at the same time
13:01:26 <fantasai> plinss: the end value of the short one has to be the partially-transitioned value of the long one
13:01:31 <jet> jet has joined #fx
13:01:42 <fantasai> plinss: that's what the author specified, so just do that
13:01:47 <fantasai> dbaron: This is a horrible effect
13:01:49 <fantasai> plinss: but they asked for it
13:02:22 <fantasai> dbaron: It's a huge amount of work to implement, is it really worth the effort for something that is slightly less horrible
13:02:35 <fantasai> plinss: If you're going to argue that people won't do it, then don't transition in this case
13:02:42 <fantasai> dbaron: It's hard to even detect this case
13:03:04 <fantasai> szilles: If I want to implement a magnify transition ...
13:03:25 <fantasai> dbaron: you probably just want to use transforms to that
13:03:41 <fantasai> dbaron: we're looking at something that would double the complexity of a transitions implementation
13:03:48 <fantasai> dbaron: to implement Peter's proposal
13:04:13 <fantasai> plinss: ok, let's back up
13:04:28 <fantasai> plinss: rune's example, is anyone saying that this shouldn't transition from 50px to 100px over 1
13:04:32 <fantasai> s
13:04:39 <fantasai> plinss: So as long as the time is the same, start to end, it's one transition
13:04:48 <fantasai> plinss: so we're agreeing on that
13:04:58 <fantasai> shane: timing function ...
13:05:13 <fantasai> dbaron: you're transitioning computed values, not cascaded values
13:05:19 <fantasai> shane: webkit doesn't do that right now
13:05:26 <fantasai> dbaron: You're transitioning in ems?
13:05:40 <fantasai> shane: oh, I'm using percentages here
13:05:49 <fantasai> dbaron: percentages are computed values; that's different
13:06:19 <fantasai> fantasai: so... if we *were* transitioning cascaded values, would that solve all these problems?
13:06:49 <fantasai> 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
13:07:26 <fantasai> Tab: If you look at the end value fo ryour width
13:07:41 <fantasai> ...
13:07:53 <fantasai> dbaron: If you have a style change, you look at the before/after values ..
13:08:01 <fantasai> Tab: The changes don't have before/after ..
13:08:08 <fantasai> dbaron: Yeah, we don't define simultaneity
13:08:25 <fantasai> Tab: If you assume simultaneity...
13:08:33 <fantasai> dbaron: Transitions are pretty dodgy. They just happen to work.
13:08:44 <fantasai> dbaron: if people care about edge cases, they should use some other mechanism
13:09:26 <fantasai> fantasai: What would happen if we transitioned on cascaded values?
13:09:40 <fantasai> dbaron: would break content
13:09:51 <fantasai> dbaron: also we don't store cascaded values
13:10:09 <fantasai> dbaron: would double or triple mem storage for properties
13:11:38 <fantasai> szilles: so if I have a 5px font size, and say that my width is 15px to 3ems, would that trigger a transition
13:11:41 <fantasai> right now, no
13:12:01 <krit> krit has joined #fx
13:12:11 <fantasai> dbaron: My proposal is to leave the spec unchanged
13:12:15 <fantasai> plinss: which means?
13:12:41 <fantasai> Tab: yeah, I guess that would increase the complexity
13:12:50 <fantasai> dbaron: It means you might get extra transitions in a bunch of cases
13:13:01 <fantasai> plinss: In Webkit right now you're getting the width transition, and then the font-size transition
13:13:55 <fantasai> dbaron: I don't think sequential is the right thing.
13:14:06 <fantasai> dbaron: I think both Gecko and Webkit do not match what the spec currently says
13:14:17 <fantasai> dbaron: I don't know why Gecko doesn't
13:14:17 <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.)
13:14:22 <fantasai> plinss: what does Gecko do?
13:14:45 <fantasai> dbaron: I think it's changing width at the end...
13:14:55 <fantasai> dbaron: I think it's computing the transition on width, assuming the prior font size
13:15:05 <fantasai> dbaron: I think this might've been intentional ...
13:15:23 <fantasai> dbaron: I think we compute each property's transition assuming a cerain set of value for the other properties
13:15:32 <fantasai> dbaron investigates
13:15:45 <fantasai> szilles: Sounds like one possible interpretation of simultaneous transitions..
13:15:58 <fantasai> szilles: I would prefer it be undefined until someone shows a use case where it would be useful
13:17:07 <fantasai> dbaron: oh! rune's testcase is not what I thought it was
13:17:16 <fantasai> dbaron: I know why Gecko behaves the way it does now
13:17:34 <fantasai> dbaron: So basically, I didn't quite implement literally what the spec says, 
13:17:57 <fantasai> dbaron: you block the effect of an inherited transition on an element you're transitioning on
13:18:09 <fantasai> dbaron: but [...]
13:18:21 <fantasai> dbaron: but I do that for everything at once
13:18:35 <fantasai> dbaron: So Gecko would behave differently here if the width were on #outer
13:19:00 <fantasai> dbaron: Because the font-size is inherited, it's ignoring it because it's an animation on an inherited property
13:19:13 <fantasai> dbaron: It's transitioning the width from 50px to 100px
13:19:22 <fantasai> dbaron: And then it jumps at the end to 300px
13:19:28 <Cyril_> Cyril_ has joined #fx
13:19:35 <fantasai> plinss: you're not computing inheritance during the transition
13:20:04 <fantasai> dbaron: We're saying, we started a transition on font-size. Now need to figure out whether we need to start transitions on descendants
13:20:12 <fantasai> dbaron: Let's block the inheritance effect ..
13:20:20 <fantasai> dbaron: But we start the wrong transition for width as a result
13:20:29 <fantasai> dbaron: But it's not a bug I can fix in any remotely performant way
13:20:56 <fantasai> dbaron: Would need to redo style resolution through the whole subtree
13:21:14 <fantasai> Tab: I understand the jumpiness and how to explain it
13:22:28 <fantasai> Tab: dbaron's way is well-defined and cheap
13:22:33 <fantasai> dbaron: But it does behave badly in this case
13:22:42 <fantasai> dbaron And rune's testcase is a reasonable testcase
13:23:29 <fantasai> plinss: So options are a) leave undefined b) define something cheap c) define something hard and correct ?
13:23:42 <fantasai> dbaron: I think you could get rune's testcase to work by following the spec
13:23:50 <fantasai> dbaron: but would still be weird if you gave different times 
13:24:04 <fantasai> dbaron: font-size 2s, width 10s
13:24:16 <fantasai> szilles: Unless someone comes up with a good use case for it, don't think you'd need it...
13:24:45 <fantasai> ...
13:24:50 <fantasai> dbaron: Talking about keeping spec as it is
13:25:04 <fantasai> dbaron: Talks about skipping a transition if change is due to inheritance
13:25:29 <fantasai> Tab thinks that's cool
13:25:34 <fantasai> szilles is confused
13:25:50 <fantasai> szilles: If I start a transition whenver it changes, would I get multiple starts as I go through the higher-level change?
13:26:09 <fantasai> szilles: 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?
13:26:29 <fantasai> dbaron: No, b/c the other rule -- dynamic change caused by an animation does not cause an animation
13:26:35 <fantasai> Tab: thought that was what I said
13:26:47 <fantasai> dbaron: No, another rule. Applies to CSS animations and SMIL, etc.
13:27:22 <fantasai> ...
13:27:28 <fantasai> dbaron: Some of this depends on your mental model
13:27:46 <fantasai> dbaron: Are you processing the transition on the parent before you compute on the children or not
13:28:10 <fantasai> szilles: ...
13:28:19 <fantasai> dbaron: future points in time not a problem
13:28:46 <fantasai> 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?
13:28:57 <fantasai> dbaron: There's one problem, which is what Steve says,
13:29:11 <fantasai> dbaron: We put this text in the spec because nothing defines the model of doing style resolution.
13:29:48 <fantasai> dbaron: 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.
13:30:00 <fantasai> Tab: Think that was the case steve was trying to call out, actually
13:30:10 <fantasai> szilles: I'd be happy not allowing that case
13:30:15 <fantasai> dbaron: Problem is detecting that case.
13:30:34 <fantasai> szilles: You have to detect it anyway b/c you have to detect subsequent changes
13:31:00 <fantasai> plinss: So, do we have a conclusion?
13:31:05 <fantasai> dbaron: I can try to write proposed text.
13:31:14 <fantasai> Florian: So you go write that, and we decide whether we like it
13:31:24 <fantasai> ACTION dbaron: write proposed text for this discussion
13:31:24 <trackbot> Created ACTION-78 - Write proposed text for this discussion [on David Baron - due 2012-05-16].
13:33:36 <fantasai> discussion of transitioning in premultiplied space
13:33:44 <fantasai> RESOLVED: transition colors in premultiplied space
13:34:06 <fantasai> issue: using floor for integer is inconsistent with SMIL and SVG
13:34:06 <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 .
13:37:01 <fantasai> ted: there was some reason for it being floor
13:37:36 <birtles> definition from SMIL is: coerced-integer-value = Math.floor( interpolated-value + 0.5 )
13:37:37 <birtles> http://www.w3.org/TR/SMIL/smil-profile.html#SMILProfileNS-animation-module
13:38:09 <fantasai> minutes of previous discussion on this: http://lists.w3.org/Archives/Public/www-style/2012Mar/0655.html
13:39:22 <fantasai> some discussion between shane and Bert on this
13:39:46 <fantasai> shane: Might make it feel like the transition hasn't kicked in
13:39:59 <fantasai> proposed to make it round(), for consistency
13:40:16 <fantasai> RESOLVED: copy SMIL's rounding of numbers to integers
13:40:59 <fantasai> cubic-bezier
13:41:15 <fantasai> dbaron: We allow cubic-bezier with y values outside the allowed range
13:41:43 <fantasai> dbaron: which means the value can be outside the allowed range of the property; since we usually check for that at parse time
13:42:09 <fantasai> dbaron: proposal is to clamp within range, e.g. while width is pushed below zero, it's treated at zero
13:42:12 <fantasai> s/at/as/
13:42:45 <fantasai> RESOLVED: clamp out-of-range values due to cubic-bezier out-of-range y values
13:43:27 <fantasai> Tab: what's marker-offset
13:43:57 <fantasai> dbaron: was in CSS2.1 and maybe CSS3 Lists
13:44:04 <fantasai> Tab: Definitely not in CSS3 Lists
13:44:08 <fantasai> s/2.1/2.0/
13:44:37 <fantasai> fantasai: don't think marker-offset should be in this list
13:44:53 <fantasai> dbaron: Could leave transform to the Transforms spec
13:44:59 <fantasai> dbaron: Don't think that spec has the Animatable lines
13:46:08 <fantasai> fantasai: background/border-radius/box-shadow are defined in css3-background already
13:46:18 <fantasai> fantasai: suggest having css3-fonts handle font-
13:46:26 <fantasai> dbaron: Ok, I will make sure they're all in the relevant modules
13:46:36 <fantasai> plinss: so not adding to this spec
13:48:01 <fantasai> fantasai: multi-col is in CR, do we add that here then?
13:48:11 <fantasai> plinss: add them, but add them at-risk
13:48:20 <fantasai> plinss: until there's 2 implementations
13:48:54 <fantasai> RESOLVED: add only multicol properties from issue 12 additions; at risk until 2 implementations known to exist
13:49:01 <fantasai> (rest go intheir respective modules)
13:49:10 <fantasai> <break duration=15m>
13:49:22 <Bert> (Backgrounds and Borders already contains the Animatable line in the propdefs)
13:52:04 <shanestephens> column-count, column-width, column-rule-color are all transition able properties in WebKit
13:53:35 <arronei_> Does anyone have a link to the updated agenda? The one on the wiki doesn't have the topics divided up by day.
13:58:34 <plinss> arronei_: today is transitions, transforms and animations, tomorrow we'll sort out the csswg agenda
13:58:57 <plinss> (unless we finish all the outstanding issues before the end of the day)
13:59:02 <arronei_> plinss: thanks wanted to make sure I didn't miss anything.
13:59:17 <plinss> oh, you're missing something alright...
13:59:20 <glazou> glazou has joined #fx
13:59:40 <arronei_> plinss: yeah I know I wish I was there. or maybe I don't :)
14:08:09 <AlexD> AlexD has joined #fx
14:09:15 <fantasai> Topic: Transforms
14:10:15 <fantasai> bug 14715 - clarify interopolation of some transform functions 
14:10:28 <fantasai> krit: some concerns on the list
14:10:41 <fantasai> krit: say that transforms of same type can be interpolated
14:10:47 <fantasai> krit: added new section for that
14:10:52 <fantasai> krit: I think this bug is closed
14:11:12 <fantasai> krit: left open in case someon thinks it's not fixed
14:11:55 <dbaron> http://dev.w3.org/csswg/css3-transforms/#animation
14:11:58 <sylvaing> http://dev.w3.org/csswg/css3-transforms/#animation
14:12:40 <fantasai> krit explains what's in the spec
14:13:19 <fantasai> dbaron: there's 2 possible ways to animate a skew
14:13:31 <fantasai> dbaron: You could animate as angle or as shear
14:14:28 <fantasai> krit: animate as angle right now
14:14:41 <fantasai> dbaron: interpolation rules should be in terms of computed values
14:14:56 <fantasai> dbaron: And computed values convert <length>s to a common unit
14:16:51 <fantasai> fantasai: unit could be anything
14:17:00 <fantasai> fantasai: although return values in the DOM are required to be in px
14:17:56 <Cyril> Cyril has joined #fx
14:18:06 <fantasai> fantasai: summary is, there's a new section in the spec. People should review the new section. Who is volunteering to review the new section?
14:18:18 <fantasai> Tab: I'll review
14:18:36 <fantasai> krit: New section about just supporting 2D part of transforms
14:18:49 <krit> http://dev.w3.org/csswg/css3-transforms/##two-dimensional-subset
14:19:12 <fantasai> krit: wanted to have some kind of fallback for UAs that don't support 3D transformations
14:19:25 <fantasai> krit: This section defines the 2D subset and specifies what to do if you don't support 3D
14:20:39 <fantasai> dbaron: simplification of [...] for 2D cases is not that simple
14:21:14 <fantasai> dbaron: the interpolation code that's referenced there will produce a 3D component in some cases
14:21:29 <fantasai> dbaron: in any case where the ? produces a change in sign between origin and destination
14:21:34 <florianr> This belongs in the previous topic, but column-count, column-width, column-rule-color are all transition able properties in Opera as well.
14:21:40 <dbaron> http://dbaron.org/css/test/2010/transition-negative-determinant
14:22:18 <fantasai> krit: For Webkit, we try to flatten 4D transforms. This is done by ... all values
14:22:27 <fantasai> krit: agree it's not the best way
14:22:36 <fantasai> krit: Current spec says you don't support 3D functions at all
14:22:44 <fantasai> dbaron: 2D and 3D specs used to be different
14:23:02 <fantasai> dbaron: ... is wrong, because simplifying for 2D case is a nontrivial case
14:23:10 <fantasai> dbaron: So you should say explicitly what happens there
14:23:21 <fantasai> dbaron: b/c Webkit shipped for multiple years with a 2D case that was wrong
14:24:20 <fantasai> fantasai: take this to the mailing list?
14:24:43 <fantasai> krit: any volunteers to review?
14:24:51 <fantasai> fantasai: I think dbaron just volunteered :)
14:25:51 <fantasai> bug 15605
14:26:29 <fantasai> dbaron: if no one in the room understands the issue, maybe ppl who do understand can work on it
14:26:54 <fantasai> krit: They have no disagreement, but not sure what they have is correct
14:27:05 <fantasai> dbaron: is this formulated as a question?
14:27:48 <fantasai> krit: in general, not really specified what happens when perspective gets zoomed
14:29:08 <fantasai> Liam talks about what happens when you multiply an axis by zero, or something
14:29:30 <fantasai> Liam: If w is zero, then don't proceed. 
14:29:38 <fantasai> Liam: Your universe is collapsed
14:29:53 <fantasai> Liam: either you don't render the thing, or it's an error
14:30:39 <fantasai> deferred to the experts not here
14:30:45 <fantasai> bug 15709
14:30:53 <Zakim> - +1.732.216.aabb
14:31:09 <fantasai> Ted: Aryeh was writing some test where the result in different implementations was the same modulo some amount of rounding
14:31:25 <fantasai> Ted: It made him unhappy when the tests were passing where there was a difference of some amount
14:31:34 <fantasai> Ted: don't think this is a Transforms issue
14:31:46 <fantasai> Tab: Should be out-of-scope for this spec
14:31:58 <fantasai> Tab: don't know how to address it
14:32:16 <dbaron> krit, btw, you should really change id="#two-dimensional-subset" to id="two-dimensional-subset" so there's not a ## in the URL
14:32:37 <fantasai> :)
14:33:09 <fantasai> next is 15871
14:33:15 <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15871
14:33:40 <fantasai> "opacity should not cause transform-style: preserve-3d to be ignored"
14:33:58 <fantasai> Tab: So in the normal case, where everything's flattened,
14:34:19 <fantasai> Tab: If you have element with 2 children, one is z-translated above, another z-translated below
14:34:39 <fantasai> Bert: Why would you not want preserve-3d?
14:34:49 <fantasai> dbaron: expensive to assume you want it on everything
14:35:06 <fantasai> dbaron: so you tell the implementation what you want to preserve 3D on, and then we flatten everything else
14:35:18 <fantasai> Tab: Yes, you tell implementations when you want the expensive path
14:35:30 <fantasai> Tab: you have to track a bunch of stuff, and that slows things down
14:35:41 <fantasai> Bert: It's trial/error to make it work
14:35:43 <cabanier> Example of preserve-3d: http://www.webkit.org/blog-files/3d-transforms/transform-style.html
14:35:54 <Zakim> disconnecting the lone participant, +49.403.063.68.aaaa, in Team_(fx)11:32Z
14:35:56 <fantasai> Ted: If you put preserve-3d on a user stylesheet and browsed the web, it would be pretty painful
14:35:56 <Zakim> Team_(fx)11:32Z has ended
14:35:56 <Zakim> Attendees were +49.403.063.68.aaaa, Tav, +1.732.216.aabb
14:36:46 <fantasai> ?: It makes sense that opacity flattens things
14:37:25 <plinss> zakim, room for 5?
14:37:27 <fantasai> Ted: Remaining disagreement is how to express this in the spec
14:37:27 <Zakim> ok, plinss; conference Team_(fx)14:37Z scheduled with code 26632 (CONF2) for 60 minutes until 1537Z; however, please note that capacity is now overbooked
14:37:35 <Zakim> Team_(fx)14:37Z has now started
14:37:40 <cabanier> ? is me
14:37:44 <Zakim> + +49.403.063.68.aaaa
14:38:03 <fantasai> plinss: so where are we at?
14:38:47 <fantasai> Ted: If no one here has an idea, we'll move on to next issue...
14:39:10 <fantasai> plinss: Do we have agreement that we want opacity to flatten it?
14:39:14 <fantasai> Ted: I really hope so
14:39:23 <fantasai> Bert: what does that mean?
14:41:00 <fantasai> Tab: So we don't flatten with opacity
14:44:22 <fantasai> Tab: We inherit opacity into the children instead of doing group opacity, that's why it works
14:44:28 <fantasai> plinss: That's not what we want
14:44:36 <fantasai> plinss: sounds like we want application of opacity flattens it
14:45:05 <fantasai> plinss: What if we then add controls to do group opacity or not?
14:45:20 <fantasai> Tab: if you don't do group opacity, you don't need to flatten
14:45:47 <fantasai> RESOLVED: Because opacity does group opacity, it flattens 3D transforms
14:46:15 <fantasai> fantasai: does this issue affect other stacking-context things?
14:47:42 <fantasai> 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)
14:48:24 <fantasai> Tab explains what preserve-3d means
14:51:54 <fantasai> ACTION hober: review wording of flatting cases to make sure all are covered, and whether should be property-by-property or generic wrt Appendix E
14:51:54 <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].
14:51:58 <krit> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15937
14:54:02 <fantasai> krit: how do you specify units of other things that aren't lengths?
14:54:17 <fantasai> dbaron: They're unitless (syntactically), but they represent units, and you need to specify what those units are
14:54:59 <fantasai> Tab: If you specify they're inches, not px, then the result would be completely different.
14:55:06 <fantasai> Tab: So you need to specify the units.
14:55:54 <krit> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15960
14:56:27 <fantasai> krit: everyone on the mailing list agreed on using quaternians
14:56:57 <fantasai> krit: I suggest to do that, and to use code from Firefox
14:57:18 <krit> http://www.euclideanspace.com/maths/geometry/rotations/conversions/matrixToQuaternion/
14:58:15 <tabatkins__> hober: Are there significant behavior differences?
14:58:40 <cabanier> gimbal lock definition: http://en.wikipedia.org/wiki/Gimbal_lock
14:59:00 <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.
14:59:24 <krit> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16328
15:00:07 <fantasai> RESOLVED: Use quaternians for rotation by translating Firefox's implementation to spec pseudo-code
15:02:39 <krit> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16377
15:03:52 <fantasai> hober proposes an action item to smfr to propose wording for the previous bug
15:03:57 <fantasai> krit: ...
15:04:06 <fantasai> krit: It's not really defined how the line should look like
15:04:09 <dbaron> s/quaternians/quaternions/
15:04:11 <fantasai> krit: is it a point or infinite line
15:04:22 <dbaron> something about non-scaling stroke
15:04:41 <fantasai> krit: ... stroke should be relative to coordinate space of parent
15:04:44 <fantasai> ??
15:04:49 <fantasai> krit: imagine you have a rect
15:04:52 <fantasai> krit: and you apply a scale
15:04:58 <fantasai> krit: the border of the rect gets scaled as well
15:05:07 <fantasai> krit: scale(2) makes it twice as big
15:05:28 <fantasai> krit: there's a property that allows not scaling the stroke
15:06:00 <fantasai> krit: when the element is skewed to zero height, what do you draw
15:07:14 <fantasai> Ted: do any implementations do anything other than not render in this case?
15:08:33 <fantasai> fantasai: so if you scale to zero height, do you see the line segment?
15:08:42 <fantasai> fantasai: skew can make an infinite line, so not render?
15:09:53 <fantasai> Liam: This was a problem in PostScript, you'd get infinite lines that seem to come from no reason
15:10:05 <fantasai> Liam: Better to vanish from the screen than to fill it
15:10:46 <fantasai> Liam: With PostScript we ended up with miter-limit and stuff like that
15:11:03 <fantasai> krit: choice of ignore transform, or not render
15:11:08 <fantasai> krit: for SVG we not render
15:12:01 <fantasai> proposal is that all singular 3D transforms don't render
15:13:59 <fantasai> szilles: easier for user to understand if they all disappear
15:14:19 <fantasai> (fantasai can't understand why scaling a rectangle to zero-height makes its non-scaling strokes also disappear)
15:15:23 <fantasai> krit: Do we draw nonscaling stroke in singular matrix, or not render
15:15:50 <fantasai> Tab: I don't think it's a non-perspective stroke
15:16:34 <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)
15:16:52 <fantasai> ...
15:17:02 <fantasai> vhardy: Talked about height of zero, height of zero makes it disappear
15:17:38 <fantasai> krit: If you have a <div> that's zero height?
15:17:43 <fantasai> fantasai: if it has a border, you see it
15:17:56 <fantasai> krit: ...
15:18:14 <fantasai> Tab: Perspective shouldn't have non-scaling stroke magic
15:18:21 <fantasai> vhardy: Which scale?
15:18:29 <fantasai> vhardy: 3D context can be anywhere
15:18:34 <smfr> smfr has joined #fx
15:18:41 <fantasai> vhardy: How do you extract what scale factor to handle?
15:18:53 <fantasai> Tab: But this isn't an issue for transforms, it's for vector-effects to define
15:18:59 <fantasai> vhardy: It only shows up for 3D transforms
15:19:07 <fantasai> vhardy: You have a perspective in 3D, right
15:19:25 <fantasai> vhardy: Ideally, your geometry would be transformed in 3D and then you'd stroke that.
15:19:43 <fantasai> vhardy: That's different from 2D, where you can compute your geometry .. and then stroke like you want on the object
15:19:56 <fantasai> vhardy: It's very simply described
15:20:02 <fantasai> vhardy: Think of stroking as computing another shape
15:20:14 <fantasai> vhardy: You can either get your geometry and then transform it
15:20:22 <fantasai> vhardy: or transform the outline first, then compute the stroke outline
15:20:31 <fantasai> vhardy: libraries don't allow you to do that
15:21:01 <fantasai> fantasai: what if you created a library that did do that?
15:21:08 <fantasai> tabatkins__: Add a new feature, call it non-perspective stroke
15:21:21 <fantasai> vhardy: Either disable non-scaling stroke altogether on 3D transforms
15:21:30 <fantasai> vhardy: or specify how you'd extract the scaled parameters
15:22:11 <fantasai> tabatkins__: if you just translateZ it you change the size...
15:22:36 <fantasai> tabatkins__: let's turn it off in all cases
15:23:45 <fantasai> Florian raises case of a transform matrix crossing zero, where it's a 2D transform for a fraction of a second
15:24:11 <fantasai> Tab: any 3D transform function anywhere in your parent chain disables non-scaling stroke
15:24:40 <fantasai> RESOLVED: as Tab proposed
15:24:59 <fantasai> RESOLVED: Don't render if the transform is singular
15:25:18 <krit> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16885
15:25:35 <fantasai> Bert: A 90deg rotation in 3D is not a singular transform?
15:25:46 <fantasai> Tab: correct; it's an invertible matrix
15:25:56 <fantasai> krit: some issues in source code
15:26:26 <fantasai> Tab: turn all the comment issues into actual <p class=issue>, remove solved/old ones, and bug any new ones
15:26:46 <smfr> i'm with Tab
15:26:52 <smfr> those comments were never intended for WG discussion
15:27:05 <smfr> editors can resolve or make issues as necessary
15:27:30 <fantasai> ACTION smfr: sift through comments in transforms spec, turn into issues or delete as appropriate
15:27:30 <trackbot> Created ACTION-80 - Sift through comments in transforms spec, turn into issues or delete as appropriate [on Simon Fraser - due 2012-05-16].
15:27:36 <fantasai> Topic: Animations
15:28:17 <sylvaing> http://lists.w3.org/Archives/Public/www-style/2012May/0189.html
15:29:06 <fantasai> sylvaing: animation-direction property has two value sbeen around for awhile: normal | alternate
15:29:10 <fantasai> er
15:29:21 <fantasai> sylvaing: Lea suggested adding reverse
15:29:26 <fantasai> sylvaing: and then alternate-reverse
15:29:34 <fantasai> sylvaing: Now that we have all these values, she has two proposals
15:29:44 <fantasai> sylvaing: One was to change the syntax of this one, it would take 
15:30:04 <fantasai> sylvaing: animation-direction: normal | alternate || reverse
15:30:11 <fantasai> sylvaing: wouldn't need to remember which is first
15:30:21 <fantasai> sylvaing: next one she proposed is redefining the feature as a new property
15:30:38 <fantasai> sylvaing: instead of thinking of it as direction of animation, think of which iterations are reversing
15:30:46 <fantasai> animation-reverse: none | all | even | odd
15:31:01 <fantasai> confusion over 0-based or 1-based counting
15:31:14 <fantasai> Florian: I think even/odd is more confusing, not really helping usability-wise
15:31:21 <fantasai> sylvaing: Lots of websites using animation-direction
15:31:40 <fantasai> Tab: I would prefer if it was intuitive and ovious which was even and which was odd, but it's not.
15:33:09 <fantasai> fantasai agrees with Florian and Tab
15:33:24 <fantasai> fantasai: I agree with Lea on the reorderable alternate-reverse syntax, though
15:33:37 <fantasai> fantasai: Would also suggest s/normal/forward/ which matches css3-marquee
15:33:49 <fantasai> dbaron: Another item in the shorthand uses forwards/backwards
15:33:56 <vhardy_> vhardy: I like the animation-reverse proposal
15:35:13 <fantasai> sylvaing: are we saying no to animation-reverse?
15:35:20 <fantasai> dbaron: Yeah, because of even/odd problem
15:35:27 <fantasai> vhardy: Could we come up with better names for even/odd?
15:35:43 <fantasai> dbaron: maybe, but it's also an issue of this going into the shorthand
15:36:33 <fantasai> dbaron: for splitting alternate-reverse, I think it's more confusing for the shorthand
15:37:14 <fantasai> dbaron: prefer to keep as one keyword so you think of it as one thing
15:37:30 <fantasai> Tab: Could add reverse-alternate as well as alternate reverse
15:37:36 <fantasai> fantasai: nooooo
15:37:56 <fantasai> fantasai: Although I would prever reverse-alternate, since you're going in reverse, then alternating
15:38:05 <dbaron> dbaron: I think most people use the shorthand rather than the longhand, and I think we should encourage that.
15:38:16 <fantasai> vhardy: ...
15:38:31 <fantasai> Tab: Spec's descriptions rely on 0-indexing
15:38:56 <fantasai> dbaron: that description is 1-based
15:39:07 <fantasai> dbaron: I write prose 1-based and code 0-based
15:39:38 <fantasai> Tab: Right, I read that wrong.
15:39:58 <fantasai> RESOLVED: no change to animation-direction syntax
15:40:46 <smfr> yay
15:41:58 <smfr> to-and-fro, fro-and-to
15:42:01 <Zakim> disconnecting the lone participant, +49.403.063.68.aaaa, in Team_(fx)14:37Z
15:42:03 <Zakim> Team_(fx)14:37Z has ended
15:42:03 <Zakim> Attendees were +49.403.063.68.aaaa
15:42:17 <sylvaing> http://lists.w3.org/Archives/Public/www-style/2011Nov/0133.html
15:43:45 <fantasai> sylvaing: so which properties do we snapshot, exactly?
15:44:00 <dbaron> At least we won't end up with 'alternate' and 'etanretla'
15:44:25 <fantasai> fantasai: sounds like someone should come up with a proposal and post it to the mailing list
15:44:51 <fantasai> dbaron: I should probably talk to smfr, and we should figure out what we agree on and disagree on
15:45:20 <fantasai> sylvaing: could defer from L3
15:45:26 <smfr> fantasai: on what topic?
15:45:32 <fantasai> dbaron: Don't have implementations on the current spec
15:45:38 <fantasai> smfr, snapshotting properties
15:45:41 <smfr> ah right
15:45:45 <fantasai> smfr, see resolution in those minutes -- they're incomplete
15:45:54 <fantasai> dbaron: concerned about simultaneity
15:46:03 <fantasai> dbaron: prefer to snapshot as little as possible
15:46:10 <fantasai> dbaron: implementations coalesce a lot, and that can vary
15:46:18 <fantasai> vhardy: work that remains to be done...
15:46:24 <fantasai> dbaron: agreeing on exactly what to snapshot
15:46:28 <smfr> i'm happy to finesse that
15:46:31 <fantasai> birtles: ok with things jumping?
15:46:44 <smfr> not sure if we'd consider changing our prefixed behavior tho
15:47:54 <fantasai> ACTION smfr: make a list of snapshotting properties for animations
15:47:54 <trackbot> Created ACTION-81 - Make a list of snapshotting properties for animations [on Simon Fraser - due 2012-05-16].
15:48:03 <smfr> hey no fair!
15:48:06 <fantasai> ACTION dbaron: Make a list of snapshotting properties for animations
15:48:07 <trackbot> Created ACTION-82 - Make a list of snapshotting properties for animations [on David Baron - due 2012-05-16].
15:48:22 <fantasai> ACTION dbaron: talk with smfr about converging on snapshotted properties list
15:48:22 <trackbot> Created ACTION-83 - Talk with smfr about converging on snapshotted properties list [on David Baron - due 2012-05-16].
15:48:23 <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14792
15:48:45 <smfr> sylvaing: i don't really have an opinion
15:49:04 <fantasai> RESOLVED: drop declaration, not @keyframes, for bug 14792
15:49:30 <sylvaing> http://lists.w3.org/Archives/Public/www-style/2011Nov/0071.html
15:50:51 <fantasai> dbaron: hard to get transitions and animations at same time [...]
15:51:06 <fantasai> dbaron: if the animation starts changing the property immediately, because it's an animation-caused style change
15:51:12 <fantasai> Tab: delay?
15:51:16 <fantasai> dbaron: Delay would let transition start
15:51:23 <fantasai> dbaron: Transitions operate on computed values
15:51:31 <fantasai> Tab: If you fill backwards, you're delay, then what?
15:51:37 <fantasai> dbaron: Then it would not trigger a style change
15:51:40 <fantasai> dbaron: well....
15:51:50 <fantasai> dbaron: if there were some othe rsimultaneous change to the property, it would
15:51:56 <fantasai> dbaron: we'd transition on that, ignoring the animation
15:52:06 <smfr> don't you people have beer to drink?
15:52:13 <fantasai> dbaron: seems to me the idea of transitions is you're taking a change that already happened
15:52:30 <fantasai> dbaron: and you're saying you want to transition between them
15:52:34 <fantasai> dbaron: it's almost on top of the cascade
15:52:53 <fantasai> dbaron: we'd start a transition, but that transition wouldn't win? but that seemed really weird
15:53:11 <fantasai> dbaron: that's why I put transitions at the top
15:53:18 <fantasai> dbaron: Transitions override animations in Gecko
15:53:32 <fantasai> dbaron: animations need to be lower, because they let you actually specify a value
15:53:47 <fantasai> dbaron: You want say, a user stylesheet that says !important, not to be overrideable by an animation
15:54:02 <fantasai> sylvaing: we put them at the override level at some point in our discussions
15:54:09 <fantasai> sylvaing: but override level is still ...
15:54:32 <fantasai> sylvaing: an animation running at the override level will still run over transition, right?
15:55:03 <fantasai> dbaron: not in Gecko
15:55:17 <fantasai> sylvaing: so transitions win, what happens to animation?
15:55:26 <fantasai> dbaron: then the animation will resume when the transition finishes
15:55:34 <fantasai> sylvaing: it resumes at that point in its timeline?
15:56:34 <fantasai> vhardy: might be an opportunity to define behavior for SVG animations
15:56:52 <fantasai> sylvaing: having transitions+animations running on the same thing, sounds like edge case
15:57:16 <fantasai> birtles: some discussion about priority of SVG and CSS animations, CSS wins
15:58:11 <dbaron> Gecko's cascade is currently:
15:58:13 <dbaron>   // Cascading order:
15:58:13 <dbaron>   // [least important]
15:58:13 <dbaron>   //  -. UA normal rules                    = Agent        normal
15:58:13 <dbaron>   //  -. User normal rules                  = User         normal
15:58:13 <dbaron>   //  -. Presentation hints                 = PresHint     normal
15:58:14 <dbaron>   //  -. Author normal rules                = Document     normal
15:58:16 <dbaron>   //  -. Override normal rules              = Override     normal
15:58:18 <dbaron>   //  -. Author !important rules            = Document     !important
15:58:20 <dbaron>   //  -. Override !important rules          = Override     !important
15:58:23 <dbaron>   //  -. animation rules                    = Animation    normal
15:58:25 <dbaron>   //  -. User !important rules              = User         !important
15:58:26 <dbaron>   //  -. UA !important rules                = Agent        !important
15:58:28 <dbaron>   //  -. transition rules                   = Transition   normal
15:58:30 <dbaron>   // [most important]
15:58:35 <fantasai> trying to figure out cases where they'd interact
15:59:06 <fantasai> Florian: button that pulsates, but when you hover over it it stops and goes back to its spot
15:59:51 <fantasai> sylvaing: we don't have that in L3
16:01:38 <fantasai> fantasai: if I have a property that's animating, and I hover over it and that changes to a different value, does it transition?
16:01:46 <fantasai> fantasai: or is the transition suppressed because it's animating?
16:01:59 <fantasai> fantasai: e.g. animating color between blue and green, on hover specify red
16:02:52 <fantasai> various conversations...
16:03:03 <fantasai> dbaron: Would be interested in hearing what IE and Webkit do
16:03:07 <fantasai> krit: animations override transitions
16:03:16 <fantasai> dbaron: let me write a testcase here...
16:04:12 <smfr> webkit hasn't implemented !important overriding animations; it's going to be hard for us to do that
16:04:24 <smfr> once we do, maybe having transitions overriding animations would be easier
16:06:41 <fantasai> 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
16:06:46 <fantasai> fantasai: the hover state is red
16:06:57 <fantasai> fantasai: let's suppose a transition does get triggered, what colors does it go between?
16:07:04 <fantasai> Florian: whatever color it's at to red
16:07:06 <fantasai> e.g. teal to red
16:07:18 <fantasai> fantasai: Makes sense, now suppose the end state is animated, e.g. between red and orange
16:07:24 <krit> http://pastebin.com/BDfVLU4W
16:07:25 <fantasai> fantasai: what color do I transition to?
16:07:36 <fantasai> Florian: Whatever color it would be at when you finish the transition
16:07:51 <fantasai> fantasai: so I line up the timelines, say the transition is 2s, right now the color is teal so I start at teal
16:08:00 <fantasai> fantasai: and I find the color at 2s into the animation, say it's orange
16:08:08 <fantasai> fantasai: and animate between teal and orange
16:08:12 <fantasai> fantasai: That seems to make sense
16:08:21 <fantasai> fantasai: don't know how hard it would be to implement, but it makes sense.
16:08:23 <dbaron> http://dbaron.org/css/test/2012/anim-and-trans
16:09:46 <fantasai> Meeting closed.
16:10:08 <shanestephens> shanestephens has joined #fx
16:10:28 <smfr> smfr has left #fx
16:10:38 <jet> jet has joined #fx
16:19:05 <kennyluck> tabatkins__, is there an agenda for the meeting today and tomorrow?
16:21:36 <dbaron> http://wiki.csswg.org/planning/hamburg-2012 is what we have
16:21:45 <dbaron> but I think the bulk of the agenda ordering is to be worked out tomorrow first thing
16:21:52 <dbaron> (today was joint CSS/SVG)
16:22:07 <kennyluck> dbaron, oh ok. Thank!
18:04:31 <Zakim> Zakim has left #fx