/irc-logs / w3c / #fx / 2012-05-09 / end

Options:

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

The end :)