IRC log of fx on 2012-05-09

Timestamps are in UTC.

06:57:19 [RRSAgent]

RRSAgent has joined #fx

06:57:20 [RRSAgent]

logging to http://www.w3.org/2012/05/09-fx-irc

06:57:26 [tabatkins__]

tabatkins__ has joined #fx

06:57:28 [ed]

Zakim, this will be FXTF

06:57:28 [Zakim]

I do not see a conference matching that name scheduled within the next hour, ed

06:57:44 [tabatkins__]

I'll be a few minutes late - voice chatting with my wife.

06:58:24 [ed]

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

07:00:08 [shanestephens]

shanestephens has joined #fx

07:01:41 [arronei_]

arronei_ has joined #fx

07:01:42 [birtles]

birtles has joined #fx

07:04:38 [ed]

Zakim, room for 8?

07:04:39 [Zakim]

ok, ed; conference Team_(fx)07:04Z scheduled with code 26632 (CONF2) for 60 minutes until 0804Z

07:04:53 [krit]

krit has joined #fx

07:04:59 [Zakim]

Team_(fx)07:04Z has now started

07:05:07 [Zakim]

+ +49.403.063.68.aaaa

07:05:22 [ed]

Topic: Transitions/Animations: New animation proposal

07:05:34 [ed]

chair: ed

07:05:40 [birtles]

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

07:07:31 [vhardy_]

vhardy_ has joined #fx

07:08:02 [jet]

jet has joined #fx

07:08:03 [vhardy_]

ScribeNick: vhardy

07:08:04 [cabanier]

cabanier has joined #fx

07:08:10 [vhardy_]

Topic: Web Animation proposal

07:08:19 [Liam]

Liam has joined #fx

07:08:22 [dbaron]

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

07:09:01 [glenn]

glenn has joined #fx

07:09:03 [vhardy_]

brian: presenting the work done on Web Animation. Work done with Shane, Rik, Tab, Dmitry, Alex, Vincent.

07:09:10 [fantasai]

fantasai has joined #fx

07:09:22 [vhardy_]

brian: trying to focus the animation effort. What we are proposing is a script API that underlies both specs.

07:09:34 [vhardy_]

... the CSS and SVG animations can be implemented in terms of that API.

07:09:55 [vhardy_]

... the API can be useful as is to script authors as well.

07:10:13 [glazou]

glazou has joined #fx

07:10:13 [vhardy_]

... we hope that as a result of this, there will be a single place to focus for animation efforts.

07:10:31 [vhardy_]

brian: I want to reflect on the initial problem we are trying to solve.

07:11:18 [vhardy_]

brian: going through the presentation at http://people.mozilla.org/~bbirtles/web-animations/presentation/web-animations.html

07:12:13 [vhardy_]

brian: discussing limitations of SVG and CSS animation models.

07:12:42 [vhardy_]

... Proposing to have script extensible declarative animations.

07:13:50 [vhardy_]

... three specifications: the Web Animations API and two specs. explaining the mapping of SVG and CSS animations to that API.

07:14:29 [vhardy_]

... In the model, an animation 'template' can generate multiple animation instances for various targets.

07:15:30 [vhardy_]

... Another key concept is grouping of a series of animations. Lets you sync. different animations. Can have a parallel group and a sequential group.

07:15:39 [vhardy_]

.... you can nest groups.

07:16:10 [vhardy_]

.. Also have a notion of template on the AnimGroup (AnimGroup/AnimGroupInstance)

07:16:52 [vhardy_]

... Model that underlies the proposal: Timing Model and Animation Model.

07:17:13 [vhardy_]

... there is a hierarchy of timelines.

07:17:37 [vhardy_]

... the nice thing is that you can use the same timing on a group or an animation.

07:18:14 [vhardy_]

... the timing model has a start time and a start delay. This allows support of the SVG timing model and more intuitive models.

07:19:03 [vhardy_]

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

07:19:15 [vhardy_]

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

07:19:42 [dbaron]

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

07:19:46 [shanestephens]

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

07:22:40 [vhardy_]

liam: is this about path morphing or motion animation?

07:22:51 [vhardy_]

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

07:23:01 [vhardy_]

jet: does the model define a sprite model?

07:23:03 [vhardy_]

alex: no

07:23:39 [vhardy_]

brian: there is a mapping between the CSS declarative animations and the objects.

07:24:38 [vhardy_]

.... similarly for SVG. The SVGAnimationElement interface inherits from Anim (from this new API)

07:25:06 [vhardy_]

.... some features are not included (such as sync. base timing).

07:25:25 [vhardy_]

... some features in the API are not in SVG yet and hopefully will be exposed in SVG 2.

07:26:08 [vhardy_]

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

07:26:26 [vhardy_]

brian: you could have more APIs in the SVG specific subclasses that could expose the sync. base graph for example.

07:26:56 [vhardy_]

brian: there is a link to the current draft that is work in progress. There is a pointer to the CSS integration draft.

07:27:00 [dbaron]

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

07:27:08 [dbaron]

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

07:27:10 [vhardy_]

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

07:27:33 [vhardy_]

krit: I have questions about the limitations. I disagree with the limitations you listed for SVG.

07:27:49 [vhardy_]

.... animations in SVG are re-usable. You can re-use them with <use> element.

07:28:09 [vhardy_]

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

07:28:18 [vhardy_]

krit: you can point to an animation from a <use>

07:28:53 [vhardy_]

.... you can synchronize the start/end of animations.

07:29:16 [vhardy_]

.... I would be interested in CSS transitions to sync. with the beginning and end of transitions.

07:29:57 [vhardy_]

.... in CSS, the timing parameters do not change after the start of the animation/transition.

07:30:03 [vhardy_]

brian: this is still in discussion I believe.

07:30:30 [vhardy_]

... we are incorporating a model where the template has a relation to its instances so that if you change the template, the instances get updated.

07:30:59 [vhardy_]

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

07:31:19 [vhardy_]

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

07:31:41 [vhardy_]

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

07:31:53 [vhardy_]

.... it should be in CSS transition as well.

07:32:13 [vhardy_]

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

07:32:51 [vhardy_]

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

07:33:26 [dbaron]

s/animation spec/transitions spec/

07:33:49 [vhardy_]

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

07:33:51 [vhardy_]

brian: yes.

07:34:04 [tabatkins__]

tabatkins__ has joined #fx

07:34:21 [vhardy_]

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

07:34:26 [vhardy_]

brian: no.

07:34:31 [vhardy_]

... it will not have any impact.

07:34:33 [sylvaing]

sylvaing has joined #fx

07:34:46 [vhardy_]

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

07:35:01 [vhardy_]

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

07:35:26 [vhardy_]

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

07:35:57 [vhardy_]

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

07:36:13 [vhardy_]

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

07:36:20 [vhardy_]

which do you expect authors to use.

07:36:58 [vhardy_]

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

07:37:08 [vhardy_]

shane: all the CSS OM would still work.

07:37:29 [vhardy_]

glazou: you would have multiple implementations on the market, some with the new API and some without.

07:37:52 [vhardy_]

... once this is in the wild, you'll have incompatible support in browsers.

07:38:07 [vhardy_]

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

07:38:25 [vhardy_]

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

07:38:39 [vhardy_]

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

07:38:53 [vhardy_]

glazou: animations are already used.

07:39:07 [vhardy_]

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

07:39:21 [vhardy_]

sylvaing: I think people will use the most interoperable.

07:39:35 [vhardy_]

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

07:39:56 [vhardy_]

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

07:40:38 [vhardy_]

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

07:40:53 [vhardy_]

(discussion on serialization).

07:41:07 [vhardy_]

brian: .. this is something we have discussed but that is not in the spec. currently.

07:41:30 [vhardy_]

... if you manipulate CSS and/or SVG animations, these are still serializable after animation.

07:41:41 [vhardy_]

s/animation/manipulation through API.

07:42:19 [vhardy_]

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

07:42:27 [vhardy_]

glazou: I am thinking of editors.

07:42:37 [vhardy_]

tab: it could be serialized to CSS.

07:42:49 [vhardy_]

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

07:43:02 [vhardy_]

shane: I think we could add support for serialization.

07:43:10 [vhardy_]

brian: this is good feedback.

07:43:23 [vhardy_]

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

07:43:40 [vhardy_]

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

07:43:54 [vhardy_]

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

07:44:28 [vhardy_]

vhardy: is there a shim for that?

07:44:41 [vhardy_]

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

07:44:49 [vhardy_]

dbaron: there was a discussion about cascading?

07:44:49 [Zakim]

+Tav

07:44:55 [Tav]

zakim, mute tav

07:44:55 [Zakim]

Tav should now be muted

07:45:21 [vhardy_]

krit: I wanted to know if there was a good definition for that? There is SVG animation, CSS animation, CSS transition and not a good model for how all that cascades.

07:45:37 [vhardy_]

... what happens if they happen at the same time on the same property?

07:46:11 [vhardy_]

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

07:46:25 [vhardy_]

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

07:46:41 [vhardy_]

dbaron: I think there is a good reason for css transitions to be on top because they operate on computed value.

07:46:57 [vhardy_]

... the fact they are on top usually won't show up because they do not react to computed value changes.

07:47:29 [vhardy_]

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

07:47:45 [vhardy_]

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

07:49:05 [vhardy_]

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

07:49:18 [vhardy_]

brian: for the case of SVG, this is what we are thinking of doing.

07:49:36 [vhardy_]

... there are some things that we are thinking could be added to CSS syntax as well.

07:50:04 [vhardy_]

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

07:50:21 [vhardy_]

brian: we have gone through that process, for example for groups.

07:50:31 [vhardy_]

... it could be worth going through this again.

07:51:29 [vhardy_]

(discussion about where transitions fit into the cascade).

07:51:39 [vhardy_]

dbaron: transitions only start when the computed value changes.

07:52:04 [vhardy_]

... if you have a rule that is so strong the computed value never changes, the transition never happens.

07:52:16 [vhardy_]

ed: what is the next step?

07:52:25 [vhardy_]

brian: is this something we should continue?

07:52:37 [cabanier]

cabanier has left #fx

07:52:54 [vhardy_]

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

07:53:09 [vhardy_]

florian: I think considering how it can be done declaratively is not quite enough.

07:53:21 [vhardy_]

.... people will ship the API before there is a declarative solution.

07:54:12 [vhardy_]

.... we should also define what the new markup should be (e.g., how do you use it with CSS animations/transitions and SVG animations). I do not want the animation API to get too ahead of the declarative solutions.

07:56:31 [vhardy_]

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

07:56:46 [vhardy_]

... I see more people using CSS animations than JQuery animations.

07:57:06 [vhardy_]

tab: CSS animations were not designed for advanced animations. The JS api is designed for that.

07:57:25 [vhardy_]

... the sort of things people are hacking css animations for today, we want to help with/correct.

07:57:40 [vhardy_]

... things are painful right now.

07:57:55 [vhardy_]

ted: people are animate things declaratively and imperatively.

07:58:12 [vhardy_]

... they'll do it both ways and it is good to rationalize the model. It seems like a win to me.

07:58:33 [vhardy_]

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

07:58:58 [vhardy_]

shane: we are in a good position to describe what is missing in the current spec.

07:59:20 [vhardy_]

... there is a mismatch between what some people want to do and the available features.

07:59:29 [vhardy_]

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

07:59:49 [vhardy_]

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

08:00:03 [vhardy_]

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

08:00:16 [vhardy_]

... what is the commitment?

08:00:38 [vhardy_]

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

08:00:54 [vhardy_]

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

08:01:07 [jdaggett]

jdaggett has joined #fx

08:02:10 [vhardy_]

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

08:02:21 [vhardy_]

dbaron: I would not draw a hard line here.

08:03:19 [vhardy_]

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

08:03:35 [vhardy_]

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

08:03:54 [vhardy_]

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

08:04:04 [vhardy_]

sylvaing: this seems to go in the right direction.

08:04:22 [vhardy_]

brian: can we continue working on this?

08:04:34 [vhardy_]

glazou: can we have a JS library for this?

08:04:40 [vhardy_]

shane: I am working on this.

08:06:16 [vhardy_]

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

08:06:30 [vhardy_]

glazou: bert is the gatekeeper of CSS declarative support.

08:06:50 [vhardy_]

... this is the first time that we are saying that we are going to replace script by script.

08:07:01 [vhardy_]

brian: this is not just the CSS wg, this is the FX task force.

08:07:33 [vhardy_]

... I am convinced about the power of declarative solutions, but we recognize that declarative markup has limits, and people will in some case step into scripts. Will we help them there.

08:07:58 [vhardy_]

glazou: I am not sure that declarative solutions have limitations. Eventually, we have always succeeded in the past.

08:08:07 [vhardy_]

... e..g, variables.

08:08:23 [vhardy_]

... eventually, the last proposal is well integrated in the spirit of CSS.

08:08:34 [vhardy_]

florian: it is hard to find simple solutions.

08:08:52 [vhardy_]

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

08:09:31 [vhardy_]

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

08:09:47 [Cyril]

Cyril has joined #fx

08:10:03 [vhardy_]

brian: event with the 10year long SMIL work, there are still cases where you need to resort to script.

08:10:13 [dbaron]

s/event/even/

08:10:20 [vhardy_]

... we should make it so that the script API can be consistent with the declarative solution and integrates.

08:10:54 [vhardy_]

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

08:11:09 [vhardy_]

alex: the most important part of this spec. is the model we are trying to define.

08:11:55 [vhardy_]

... I prefer declarative too. We are trying to fix that you cannot synchronize, priorities on animations, make something that covers the CSS animations, transitions and SMIL model.

08:12:21 [vhardy_]

... this is what we are trying to get right. Whether this is expressed as script or declarative, this is an orthogonal problem.

08:12:39 [vhardy_]

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

08:13:14 [vhardy_]

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

08:14:12 [vhardy_]

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

08:14:32 [vhardy_]

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

08:14:45 [vhardy_]

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

08:14:57 [vhardy_]

glazou: should we have a single document?

08:15:14 [vhardy_]

.. you could start editors draft separately, but you could join them later.

08:15:18 [vhardy_]

(several agree).

08:15:45 [Bert]

Bert has joined #fx

08:15:47 [vhardy_]

Topic: CSS Transform update

08:16:33 [vhardy_]

krit: we had a discussion about the SVG part of CSS transform.

08:16:40 [vhardy_]

.... here is the list of general CSS issues.

08:16:51 [ed]

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

08:17:04 [ed]

http://dev.w3.org/csswg/css3-transforms/

08:17:13 [AD]

AD has joined #fx

08:17:14 [vhardy_]

krit: for the 3D part, I am relying on the other editors. There is a problem with the perspective.

08:17:16 [birtles_]

birtles_ has joined #fx

08:17:40 [vhardy_]

... the editors are still unsure how to address the issue, we are waiting for more implementation feedback. The other issue is about the containing block.

08:18:11 [vhardy_]

... we re-wrote some parts like section 14 (The Transform Functions).

08:18:41 [vhardy_]

... the SVG and 2D issues can be addressed in the next two weeks. The 3D issues require more feedback from implementors.

08:18:49 [vhardy_]

ed: do you want a resolution to publish?

08:19:02 [vhardy_]

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

08:19:11 [vhardy_]

ed: everybody fine with publishing a new WD

08:19:31 [vhardy_]

RESOLVED: The task force agrees to publish a new version of the CSS Transform specification draft.

08:19:43 [vhardy_]

ed: break now.

08:19:47 [vhardy_]

(15mn)

08:20:01 [Zakim]

-Tav

08:25:02 [Zakim]

disconnecting the lone participant, +49.403.063.68.aaaa, in Team_(fx)07:04Z

08:25:04 [Zakim]

Team_(fx)07:04Z has ended

08:25:04 [Zakim]

Attendees were +49.403.063.68.aaaa, Tav

08:37:39 [nikos_]

nikos_ has joined #fx

08:38:53 [jen]

jen has joined #fx

08:38:59 [heycam]

ScribeNick: heycam

08:39:13 [ed]

topic: CSS Compositing and blending

08:39:21 [ed]

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

08:40:04 [heycam]

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

08:40:12 [heycam]

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

08:40:17 [heycam]

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

08:40:21 [heycam]

… designers already use this

08:40:24 [heycam]

… they want to use it in web tools

08:40:29 [heycam]

… currently they must rasterise

08:40:36 [heycam]

… so it'd be better to support this natively

08:40:41 [heycam]

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

08:40:49 [heycam]

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

08:40:57 [heycam]

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

08:41:07 [heycam]

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

08:41:17 [heycam]

… windows 8 exposes an api to do it natively

08:41:32 [heycam]

… there was an SVG spec before, tailored towards SVG

08:41:38 [heycam]

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

08:41:46 [heycam]

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

08:41:50 [heycam]

… it doesn't talk about buffers, just shapes

08:42:03 [heycam]

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

08:42:06 [heycam]

… so we pulled them apart

08:42:22 [heycam]

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

08:42:32 [heycam]

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

08:42:39 [heycam]

… thirdly, how this applies to the CSS box model

08:42:46 [heycam]

… fourth, optionally, how this applies to canvas

08:42:55 [heycam]

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

08:43:06 [heycam]

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

08:43:12 [heycam]

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

08:43:32 [heycam]

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

08:43:44 [heycam]

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

08:43:57 [AD]

AD has joined #fx

08:44:00 [heycam]

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

08:44:07 [heycam]

… another part the spec goes over is group alpha

08:44:20 [heycam]

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

08:44:29 [heycam]

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

08:44:35 [heycam]

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

08:44:43 [heycam]

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

08:44:58 [heycam]

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

08:46:07 [heycam]

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

08:46:20 [heycam]

… the next section talks about porter-duff

08:46:27 [heycam]

… this is primitive blending operations

08:46:33 [heycam]

… firefox and webkit have this under the hood

08:46:36 [heycam]

… and we want to expose it to the API

08:46:47 [heycam]

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

08:46:49 [krit]

krit has joined #fx

08:46:51 [heycam]

… we talk about how they work with groups

08:46:58 [heycam]

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

08:47:03 [heycam]

… we also discuss knockout behaviour

08:47:10 [heycam]

… and clip-to-self

08:47:25 [heycam]

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

08:47:30 [heycam]

… which is the PDF rendering model

08:47:36 [heycam]

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

08:47:46 [heycam]

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

08:47:53 [vhardy_]

vhardy_ has joined #fx

08:47:59 [heycam]

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

08:48:07 [heycam]

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

08:48:34 [heycam]

… it also describes how blending interacts with groups and isolation

08:48:41 [heycam]

… and again how knockout behaviour works

08:48:48 [heycam]

… the next section is how you use this from css

08:49:03 [heycam]

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

08:49:18 [heycam]

… (which are also used in canvas)

08:49:27 [heycam]

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

08:49:42 [heycam]

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

08:49:47 [heycam]

alex: no

08:49:50 [heycam]

rik: [demos]

08:53:32 [heycam]

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

08:53:43 [heycam]

[as opposed to SVG content]

08:53:50 [heycam]

rik: then we have the keywords for blending in CSS

08:54:02 [heycam]

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

08:54:11 [heycam]

… the 'isolation' property auccumulate | isodlate

08:54:21 [heycam]

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

08:55:02 [heycam]

… [demo of blend modes with two photographs]

08:56:20 [heycam]

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

08:56:43 [heycam]

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

08:56:50 [heycam]

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

08:56:53 [heycam]

rik: for background images?

08:57:05 [heycam]

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

08:57:11 [heycam]

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

08:57:16 [heycam]

dbaron: even with alpha-compositing?

08:57:17 [heycam]

dbaron: yes

08:57:21 [heycam]

s/dbaron/rik/

08:57:38 [heycam]

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

08:58:06 [heycam]

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

08:58:17 [heycam]

nikos: any discrete thing is a group

08:58:23 [heycam]

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

08:58:27 [heycam]

rik: no, they're in the same group

08:58:37 [heycam]

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

08:58:52 [heycam]

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

08:58:57 [heycam]

rik: yes but this keyword later can change this

08:59:08 [heycam]

… designers have said they want this behaviour

08:59:21 [heycam]

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

09:00:01 [heycam]

rik: [demos an image blending with itself]

09:00:08 [heycam]

… photoshop users often do this to beef up the contrast

09:01:40 [heycam]

… [demos blended video]

09:01:58 [heycam]

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

09:02:03 [heycam]

… this is a bit up in the air still

09:02:16 [heycam]

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

09:02:28 [heycam]

… list of porter duff operators, one for each background

09:02:37 [heycam]

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

09:02:59 [heycam]

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

09:03:05 [heycam]

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

09:03:09 [heycam]

… maybe they can be collapsed into one

09:04:01 [heycam]

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

09:04:11 [heycam]

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

09:04:15 [heycam]

vhardy: it could be in the value here too

09:05:05 [heycam]

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

09:05:19 [heycam]

… as in not within some other child element?

09:05:31 [heycam]

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

09:05:32 [heycam]

rik: it would apply

09:05:43 [heycam]

dbaron: I actually prefer not separating the contents

09:06:08 [heycam]

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

09:06:09 [heycam]

rik: yes

09:06:14 [heycam]

… we haven't implemented these three properties yet

09:06:28 [heycam]

… next we have keywords for adding blending to canvas

09:06:50 [heycam]

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

09:06:55 [heycam]

… should it be separate?

09:07:06 [heycam]

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

09:07:17 [heycam]

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

09:07:25 [heycam]

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

09:07:36 [heycam]

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

09:07:52 [heycam]

dbaron: the alpha compositing does affect the colour channels

09:07:59 [heycam]

alex: but only in terms of how much it lightens

09:08:08 [heycam]

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

09:08:16 [heycam]

… alpha compositing with opacity=1 is just the soure

09:08:21 [heycam]

… as you drop alpha, it changes the colour

09:08:32 [heycam]

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

09:08:38 [heycam]

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

09:08:41 [heycam]

s/soure/source/

09:08:55 [heycam]

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

09:08:59 [heycam]

tab: it's just that the math looks imilar

09:09:02 [heycam]

s/imilar/similar/

09:09:08 [heycam]

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

09:09:18 [heycam]

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

09:09:27 [heycam]

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

09:09:37 [heycam]

rik: and it makes things easier to describe

09:09:46 [heycam]

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

09:09:59 [heycam]

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

09:10:15 [heycam]

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

09:10:31 [heycam]

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

09:11:03 [heycam]

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

09:11:29 [heycam]

… we have prototype implementations for webkit, chromium and firefox

09:11:32 [heycam]

… in chromium we use the gpu

09:11:39 [heycam]

… there are some issues in the current spec

09:11:51 [heycam]

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

09:12:02 [heycam]

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

09:12:07 [heycam]

… but that might make implementations more difficult

09:12:25 [heycam]

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

09:12:33 [heycam]

… which you'd need to do twice

09:12:37 [heycam]

… the same applies to knock-out

09:12:48 [heycam]

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

09:13:05 [heycam]

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

09:13:29 [heycam]

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

09:14:01 [heycam]

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

09:14:29 [heycam]

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

09:14:49 [heycam]

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

09:15:03 [heycam]

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

09:15:11 [heycam]

rik: I'm neutral on the splitting

09:15:16 [heycam]

florian: I'd say don't split yet

09:15:27 [heycam]

rik: we have working prototypes

09:15:51 [heycam]

… for chromium we have hardware acceleration

09:16:00 [heycam]

… in in webkit, it calls into Core Graphics

09:16:02 [heycam]

s/in in/in/

09:16:24 [heycam]

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

09:16:30 [heycam]

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

09:16:37 [heycam]

… the porter duff section needs to be clarified a bit

09:16:48 [heycam]

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

09:17:01 [heycam]

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

09:17:09 [heycam]

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

09:17:13 [heycam]

rik: the keyword or the model?

09:17:20 [heycam]

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

09:17:30 [heycam]

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

09:17:35 [heycam]

vhardy: there are more than three sentences

09:17:40 [heycam]

nikos: in section 3

09:17:53 [heycam]

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

09:18:07 [heycam]

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

09:18:16 [heycam]

rik: the background is basically everything that is rendered before

09:18:25 [heycam]

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

09:18:31 [heycam]

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

09:18:38 [heycam]

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

09:18:42 [heycam]

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

09:18:46 [heycam]

rik: it's the same rules

09:19:04 [heycam]

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

09:19:11 [heycam]

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

09:19:21 [heycam]

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

09:19:32 [heycam]

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

09:19:42 [heycam]

rik: enable-background creates a new stacking context

09:19:46 [heycam]

… that's something that's not there today

09:19:53 [heycam]

… everything browsers do currently is accumulate

09:20:04 [heycam]

… the background calculation will take some time to do

09:20:19 [heycam]

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

09:20:32 [heycam]

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

09:20:44 [heycam]

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

09:20:50 [heycam]

tab: SVG definitely does make that distinction

09:20:55 [heycam]

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

09:21:01 [heycam]

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

09:21:06 [heycam]

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

09:21:14 [heycam]

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

09:21:17 [heycam]

… that's only to do with SVG Filters

09:21:29 [heycam]

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

09:21:40 [heycam]

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

09:21:44 [heycam]

… but blending doesn't require that

09:21:53 [heycam]

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

09:22:08 [heycam]

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

09:22:19 [heycam]

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

09:22:25 [heycam]

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

09:22:32 [heycam]

rik: it applies to the rastered parts of the group

09:22:38 [heycam]

alex: blending is different from filters

09:22:44 [heycam]

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

09:22:48 [heycam]

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

09:22:59 [heycam]

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

09:23:07 [heycam]

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

09:23:16 [heycam]

alex: stacking context is the wrong term

09:23:30 [heycam]

… it's a new rendering surface

09:23:36 [heycam]

dirk: so you draw the group into a new bitmap

09:23:40 [heycam]

dbaron: it's like a new group

09:24:01 [heycam]

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

09:24:08 [heycam]

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

09:24:17 [heycam]

… it's essentially like saying opacity:0.9999

09:24:18 [heycam]

alex: yes

09:24:25 [heycam]

dbaron: except it also has this effect on SVG Filters

09:24:38 [heycam]

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

09:24:43 [heycam]

… but that's orthogonal to this

09:25:16 [heycam]

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

09:25:51 [heycam]

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

09:25:57 [heycam]

alex: not sure what you mean

09:25:59 [heycam]

nikos: both I think

09:26:07 [heycam]

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

09:26:13 [heycam]

dbaron: the alpha-compisitng property applies to all elements

09:26:28 [heycam]

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

09:26:37 [heycam]

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

09:26:41 [heycam]

s/compisitng/compositing/

09:26:55 [heycam]

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

09:27:08 [heycam]

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

09:27:12 [heycam]

… is blend mode the same way?

09:27:15 [heycam]

alex: yes

09:27:27 [heycam]

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

09:27:47 [heycam]

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

09:27:59 [heycam]

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

09:28:08 [heycam]

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

09:28:13 [heycam]

… which has just three sentences

09:28:17 [heycam]

rik: that needs to be fixed

09:28:25 [heycam]

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

09:28:31 [heycam]

alex: or even of what enable-background does

09:28:44 [heycam]

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

09:28:48 [heycam]

… since it doesn't talk about groups

09:28:57 [heycam]

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

09:29:05 [heycam]

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

09:29:12 [heycam]

dirk: can it reference Filters?

09:29:19 [heycam]

alex: they're for different purposes, so no

09:29:38 [heycam]

rik: it does kind of describe the same thing

09:29:53 [heycam]

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

09:29:58 [heycam]

alex: it still just implies creating a buffer

09:30:07 [heycam]

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

09:30:12 [heycam]

… but draw into an offscreen is all it says

09:30:19 [heycam]

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

09:31:06 [heycam]

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

09:31:20 [heycam]

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

09:31:21 [heycam]

alex: it is

09:31:38 [heycam]

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

09:31:42 [heycam]

… BackgroundImage in Filters requires that

09:31:50 [heycam]

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

09:32:01 [heycam]

dirk: my question was just whether this can references Filters

09:32:07 [heycam]

rik: for just the background generation? yes

09:32:11 [heycam]

… but we need to define the model here

09:32:23 [heycam]

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

09:32:24 [heycam]

rik: yes

09:32:38 [heycam]

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

09:32:48 [heycam]

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

09:33:02 [heycam]

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

09:33:35 [heycam]

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

09:33:38 [heycam]

… for an author it's not trivial

09:33:44 [heycam]

… but if there are good use cases

09:33:57 [heycam]

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

09:33:59 [heycam]

rik: I can think of some

09:34:07 [heycam]

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

09:34:16 [heycam]

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

09:34:30 [heycam]

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

09:34:44 [heycam]

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

09:34:53 [heycam]

vhardy: they're the same but for different purposes

09:35:49 [heycam]

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

09:36:01 [heycam]

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

09:36:14 [heycam]

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

09:36:31 [heycam]

vhardy: the section of background calculation should help

09:36:37 [heycam]

tab: but a higher level description would be good

09:36:41 [heycam]

… I'll suggest some text for that

09:36:55 [heycam]

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

09:37:21 [heycam]

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

09:37:29 [heycam]

… you might want to do this in JS

09:37:32 [heycam]

rik: you could do it in shaders

09:37:38 [heycam]

… we already have filter effects

09:37:46 [heycam]

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

09:38:00 [heycam]

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

09:38:12 [heycam]

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

09:38:25 [heycam]

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

09:38:48 [heycam]

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

09:39:00 [heycam]

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

09:39:08 [heycam]

jet: are you exposing that? color matrix?

09:39:12 [heycam]

alex: no

09:39:19 [heycam]

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

09:39:28 [heycam]

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

09:39:34 [heycam]

dbaron: SVG has this

09:39:38 [heycam]

vhardy: but it's uniform over the image

09:39:43 [heycam]

… here you could do it per pixel

09:40:01 [heycam]

erik: are you waiting for more edits before publication?

09:40:03 [heycam]

nikos: more comments

09:40:11 [heycam]

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

09:40:17 [heycam]

… I think the sooner we get wider review the better

09:40:21 [heycam]

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

09:40:27 [heycam]

rik: the once that we ant, yes

09:40:30 [heycam]

s/ant/want/

09:40:38 [heycam]

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

09:40:53 [heycam]

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

09:41:01 [heycam]

… since big images don't need to be downloaded

09:41:15 [heycam]

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

09:41:20 [heycam]

florian: before publishing?

09:41:27 [heycam]

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

09:41:34 [heycam]

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

09:41:40 [heycam]

rik: it is hard to make it easy

09:41:59 [heycam]

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

09:42:16 [heycam]

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

09:42:23 [heycam]

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

09:42:35 [heycam]

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

09:42:52 [heycam]

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

09:42:58 [heycam]

… some of these properties don't have descriptions yet

09:43:10 [heycam]

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

09:43:29 [heycam]

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

09:43:46 [heycam]

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

09:43:53 [heycam]

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

09:44:01 [heycam]

nikos: I wouldn't be comfortable publishing yet

09:44:12 [heycam]

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

09:44:19 [heycam]

rik: there is more elsewhere in the spec

09:44:25 [heycam]

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

09:45:16 [heycam]

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

09:45:26 [heycam]

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

09:46:29 [heycam]

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

09:46:35 [heycam]

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

09:46:43 [heycam]

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

09:46:48 [heycam]

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

09:46:53 [heycam]

tab: for the blending modes, that's understandable

09:47:01 [heycam]

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

09:47:09 [heycam]

… they're not sufficiently understandable to get feedback on

09:47:12 [heycam]

… the grouping stuff

09:47:22 [heycam]

nikos: I will work on that with Rik

09:48:14 [heycam]

Topic: Filter effects

09:48:21 [heycam]

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

09:48:25 [ed]

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

09:48:32 [ed]

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

09:49:09 [heycam]

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

09:49:16 [heycam]

… we were able to demonstrate that with css shaders

09:49:31 [heycam]

… there have been many options described

09:49:43 [heycam]

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

09:49:55 [heycam]

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

09:49:58 [heycam]

s/group/graph/

09:50:09 [heycam]

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

09:50:13 [heycam]

… we implemented this, worked well

09:50:14 [ed]

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

09:50:24 [heycam]

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

09:50:39 [heycam]

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

09:50:50 [heycam]

… NaNs and infinities take different computation time

09:51:06 [heycam]

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

09:51:19 [heycam]

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

09:51:25 [heycam]

… which is the access to the rendered content

09:51:29 [heycam]

… it's problematic for 2 reasons

09:51:34 [heycam]

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

09:51:45 [heycam]

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

09:51:49 [heycam]

… it's a whack-a-mole problem

09:52:05 [heycam]

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

09:52:14 [heycam]

… so the current proposal is to remove texture access completely

09:52:23 [heycam]

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

09:52:31 [heycam]

… I wanted to show you demos under these limitations

09:52:44 [heycam]

… the first one is a greyscale effect

09:53:06 [heycam]

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

09:53:21 [heycam]

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

09:53:55 [heycam]

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

09:54:06 [heycam]

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

09:54:56 [heycam]

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

09:55:11 [heycam]

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

09:55:25 [heycam]

… this is still possible with the restrictions

09:55:34 [heycam]

… [demo of folded paper effect]

09:55:39 [heycam]

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

09:55:52 [heycam]

… the shader is interesting

09:56:00 [heycam]

… it computes two things

09:56:10 [heycam]

… the gl_Position, the distortion of the surface

09:56:18 [heycam]

… and it also generates a shadow parameters

09:56:21 [heycam]

s/parameters/parameter/

09:56:33 [heycam]

… the fragment shader takes the shadow

09:56:46 [heycam]

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

09:56:58 [heycam]

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

09:57:04 [heycam]

… but already this provides some useful features

09:57:25 [heycam]

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

09:57:33 [heycam]

… with a different formulation of the shaders

09:57:43 [heycam]

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

09:57:53 [heycam]

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

09:57:58 [heycam]

… and then move the spec to FPWD

09:58:08 [heycam]

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

09:58:19 [heycam]

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

09:58:55 [heycam]

… this should make the picking easier?

09:59:01 [heycam]

vhardy: I don't think it changes picking much

09:59:07 [heycam]

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

09:59:47 [heycam]

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

09:59:58 [heycam]

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

10:00:28 [heycam]

Topic: Test the Web Forward

10:00:52 [heycam]

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

10:00:58 [heycam]

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

10:01:04 [heycam]

… the first part will be education for people

10:01:13 [heycam]

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

10:01:17 [heycam]

… and set them up for review

10:01:32 [heycam]

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

10:01:39 [heycam]

… so that there are positive contributions to the test suites

10:01:55 [heycam]

alan: Friday 15th and Saturday 16th of June

10:02:16 [heycam]

fantasai: can we make this an official FXTF event?

10:02:24 [heycam]

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

10:02:32 [heycam]

vhardy: I think they're already coming

10:02:35 [heycam]

sylvaing: I think it'll be fine

10:03:01 [heycam]

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

10:03:12 [heycam]

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

10:03:21 [heycam]

… so I'd rather it be a W3C event

10:03:30 [heycam]

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

10:03:43 [heycam]

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

10:03:51 [heycam]

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

10:03:53 [heycam]

fantasai: that's fine

10:04:01 [heycam]

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

10:04:25 [heycam]

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

10:04:36 [heycam]

… to help people out on all aspects of test development

10:04:47 [heycam]

… version control, test review or just general CSS questions

10:04:54 [heycam]

hober: that's the weekend just after WWDC

10:05:12 [heycam]

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

10:05:21 [heycam]

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

10:05:51 [heycam]

heycam: how much focus is there on SVG here?

10:06:01 [heycam]

vhardy: we need some help there from SVG people

10:06:09 [heycam]

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

10:06:22 [heycam]

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

10:06:36 [heycam]

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

10:06:48 [heycam]

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

10:06:55 [heycam]

vhardy: Dirk will be there

10:07:07 [heycam]

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

10:07:18 [heycam]

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

10:07:31 [heycam]

vhardy: not sure

10:07:40 [heycam]

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

10:07:45 [heycam]

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

10:07:49 [heycam]

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

10:08:05 [heycam]

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

10:08:18 [heycam]

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

10:08:25 [heycam]

s/afternoon/mid-afternoon/

10:09:01 [Zakim]

Zakim has left #fx

10:09:21 [heycam]

heycam: hopefully we have our Sheperd set up by then

10:09:25 [heycam]

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

10:10:13 [heycam]

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

10:10:33 [heycam]

ACTION: Erik to find out who from SVG WG will attend the FXTF hackathon

10:10:33 [trackbot]

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

10:10:53 [heycam]

Topic: SVG attributes becoming properties

10:10:55 [ed]

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

10:10:56 [Zakim]

Zakim has joined #fx

10:11:04 [heycam]

Zakim, room for 5?

10:11:06 [Zakim]

ok, heycam; conference Team_(fx)10:11Z scheduled with code 26632 (CONF2) for 60 minutes until 1111Z

10:11:53 [Zakim]

Team_(fx)10:11Z has now started

10:12:01 [Zakim]

+ +49.403.063.68.aaaa

10:12:45 [Zakim]

+ +1.732.216.aabb

10:13:19 [cabanier]

cabanier has joined #fx

10:13:39 [heycam]

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

10:13:48 [heycam]

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

10:14:16 [heycam]

… let's go through the issues

10:14:35 [heycam]

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

10:14:39 [heycam]

… it might be confusing to use different properties

10:14:56 [heycam]

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

10:15:03 [heycam]

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

10:15:10 [heycam]

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

10:15:20 [heycam]

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

10:15:27 [heycam]

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

10:15:44 [heycam]

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

10:15:50 [heycam]

… but cx would apply to only two elements ever

10:15:54 [heycam]

… and that's just kind of nasty

10:16:15 [heycam]

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

10:16:23 [heycam]

dirk: you can say the same for x and y

10:16:26 [heycam]

… they apply to only some elements

10:16:39 [heycam]

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

10:16:47 [heycam]

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

10:16:50 [heycam]

erik: fx/fy?

10:16:55 [heycam]

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

10:17:01 [heycam]

erik: the proposal has the list of elements

10:17:15 [heycam]

erik: x1, x2, y1, y2 for <line>

10:17:29 [heycam]

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

10:17:33 [heycam]

… short meaningless names

10:17:37 [heycam]

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

10:17:43 [heycam]

fantasai: at least expanding them out to something more obvious

10:17:50 [heycam]

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

10:17:56 [heycam]

… in general we don't want to prefix

10:18:02 [heycam]

… for example maybe the positioning ones, just prefix

10:18:09 [heycam]

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

10:18:22 [heycam]

fantasai: another issue is these are all studlyCaps

10:18:28 [heycam]

… we use dashes in between words

10:19:44 [heycam]

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

10:19:52 [heycam]

tab: we could alias

10:20:44 [heycam]

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

10:20:52 [heycam]

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

10:21:45 [heycam]

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

10:21:49 [heycam]

… when they want to use the properties now

10:22:06 [heycam]

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

10:22:12 [heycam]

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

10:22:25 [heycam]

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

10:22:29 [heycam]

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

10:22:35 [heycam]

hober: the prefix is a compromise in this case

10:22:37 [heycam]

… there's an obvious mapping

10:22:43 [heycam]

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

10:23:17 [heycam]

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

10:23:24 [heycam]

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

10:23:30 [heycam]

… that's something that bothers me here

10:23:51 [heycam]

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

10:23:57 [heycam]

fantasai: anything three letters or less

10:24:01 [heycam]

hober: and several that are longer

10:24:10 [heycam]

dbaron: radius-x would be the minimum for rx

10:24:59 [heycam]

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

10:25:41 [heycam]

hober: you'll need to have a table

10:25:50 [heycam]

… I think using a prefix is a good compromise

10:26:00 [heycam]

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

10:26:10 [heycam]

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

10:27:21 [heycam]

heycam: were the other proposals acceptable?

10:27:26 [heycam]

jen: I think yes, for the most part

10:27:30 [heycam]

… the key here is the functionality

10:27:51 [heycam]

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

10:28:35 [heycam]

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

10:28:40 [heycam]

… and try tyo align them

10:29:05 [heycam]

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

10:30:07 [heycam]

ACTION: Cameron to propose new CSS-friendly names for SVG attributes promoted to properties

10:30:07 [trackbot]

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

10:30:47 [ed]

-- lunch break --

10:30:59 [Zakim]

- +1.732.216.aabb

10:37:00 [glazou]

glazou has joined #fx

10:38:45 [jet]

jet has joined #fx

10:57:54 [tantek]

tantek has joined #fx

10:59:01 [tantek]

tantek has joined #fx

10:59:38 [tantek]

tantek has joined #fx

11:06:07 [Cyril]

Cyril has joined #fx

11:16:01 [Zakim]

disconnecting the lone participant, +49.403.063.68.aaaa, in Team_(fx)10:11Z

11:16:04 [Zakim]

Team_(fx)10:11Z has ended

11:16:04 [Zakim]

Attendees were +49.403.063.68.aaaa, +1.732.216.aabb

11:17:18 [jen]

jen has joined #fx

11:29:45 [jet]

jet has joined #fx

11:31:59 [tabatkins__]

tabatkins__ has joined #fx

11:32:49 [ed]

Zakim, room for 5?

11:32:51 [Zakim]

ok, ed; conference Team_(fx)11:32Z scheduled with code 26632 (CONF2) for 60 minutes until 1232Z

11:33:16 [glazou]

glazou has joined #fx

11:34:04 [Zakim]

Team_(fx)11:32Z has now started

11:34:12 [Zakim]

+ +49.403.063.68.aaaa

11:34:16 [AlexD]

AlexD has joined #fx

11:35:03 [ed]

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

11:35:07 [fantasai]

Scribe: fantasai

11:35:53 [fantasai]

ed: issue of having different notations, e.g. scientific notation

11:36:16 [fantasai]

ed: also question of units -- SVG units are optional

11:36:25 [fantasai]

ed: proposal is to keep parsing of presentational attributes the same

11:36:33 [vhardy_]

vhardy_ has joined #fx

11:37:25 [fantasai]

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

11:37:32 [ed]

topic: SVG attributes becoming properties

11:38:02 [fantasai]

brief exchange on scientific notation in CSS

11:38:13 [fantasai]

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

11:39:08 [fantasai]

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

11:39:15 [fantasai]

(obviously)

11:39:28 [Zakim]

+Tav

11:39:47 [Tav]

zakim, mute tav

11:39:47 [Zakim]

Tav should now be muted

11:40:00 [fantasai]

Tab wants to later discuss scientific notation in CSS

11:40:32 [glazou]

it's a CSS pixel dammit !

11:40:32 [fantasai]

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

11:41:29 [fantasai]

fantasai: SVG properties and attributes both?

11:41:32 [fantasai]

krit: yes

11:41:44 [fantasai]

Bert: So we (CSS) can indirectly change the definition of SVG?

11:41:56 [fantasai]

Bert: Not sure that's a good idea...

11:42:57 [fantasai]

krit: All CSS units should be supported in SVG, regardless of whether the viewer support SVG

11:43:07 [vhardy_]

vhardy_ has joined #fx

11:43:40 [fantasai]

krit: Just if you write content with the new units, it won't work in older SVG clients

11:43:43 [krit]

s/support SVG/support CSS/

11:44:14 [fantasai]

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

11:44:27 [fantasai]

Bert: That's not really standardization...

11:44:40 [fantasai]

Bert: Shouldn't rely on a product to define the specification.

11:45:00 [fantasai]

Bert: Tab is saying you don't need a spec, just do what the browsers do.

11:45:54 [fantasai]

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

11:46:48 [Zakim]

+ +1.732.216.aabb

11:47:08 [fantasai]

ed: third issue, certain things that used to be content in SVG are now styleable

11:47:11 [fantasai]

ed: e.g. width/height

11:47:22 [fantasai]

ed: proposed resolution is to just accept that

11:47:56 [fantasai]

ed: implication is that you no longer have to put them in the content

11:48:39 [fantasai]

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

11:48:55 [tabatkins__]

s/?/krit/

11:49:02 [fantasai]

krit: They'll default to zero

11:49:13 [vhardy_]

vhardy_ has joined #fx

11:49:53 [fantasai]

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

11:50:13 [fantasai]

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

11:50:21 [fantasai]

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

11:51:05 [fantasai]

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

11:51:12 [fantasai]

ed: it's not invalid today, just doesn't render

11:51:49 [fantasai]

ed: think we need to work out the issues more exactly

11:52:08 [fantasai]

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

11:52:30 [fantasai]

Bert: Are you expecting that the values that don't make sense are valid? Or do you want to say it's invalid?

11:52:42 [fantasai]

Bert: It happens to have a meaning when applied to CSS typography, but

11:52:50 [fantasai]

vhardy: That would require discussion

11:54:13 [fantasai]

ACTION SVGWG: make proposal more concrete

11:54:14 [trackbot]

Sorry, couldn't find user - SVGWG

11:54:59 [fantasai]

ed: ... list that MS came up with,

11:55:05 [fantasai]

ed: reasonably simple list of attributes

11:55:24 [fantasai]

ed: s/.../list of attributes being "upgraded" to properties/

11:55:49 [fantasai]

ed: list could be made longer, or just accept this as a starting point

11:55:56 [fantasai]

Tab: I'm down with that

11:56:39 [fantasai]

ed: issue of SVG and CSS properties that have different syntax

11:56:47 [fantasai]

ed: That has to be dealt with somehow

11:56:54 [fantasai]

dbaron: Sounds like they're different CSS properties

11:57:16 [fantasai]

Tab: e.g. make text properties start with text-

11:57:40 [fantasai]

Tab: Happen to share a name in SVG, but are actually different attributes

11:58:38 [fantasai]

Bert: ...

11:58:51 [fantasai]

Bert: if you have a UA that does both SVG and CSS, how do you know whether it applies or not?

11:59:13 [fantasai]

Bert: I'm not sure there's a solution for that, but sounds like you're trying to merge things together that might be too different to merge

11:59:29 [fantasai]

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

11:59:42 [fantasai]

Bert: In CSS if it doesn't parse right, you ignore it.

12:00:02 [fantasai]

Bert: you can't parse differently depending on whether it applies to an SVG element or not

12:00:09 [fantasai]

krit: We already have this problem with e.g. font-size

12:00:23 [fantasai]

krit: In SVG, you can put unitless values, but in CSS property you have to put units

12:01:49 [fantasai]

krit explains to Bert how this works

12:03:43 [fantasai]

Bert: If I write font-size: 7;, it's ignored

12:03:53 [fantasai]

Bert: Unless I do it in SVG, then it works.

12:04:09 [fantasai]

krit: If you transition from 7 to 18px, it works

12:04:25 [fantasai]

krit: The CSS parser doesn't allow bare numbers.

12:06:18 [fantasai]

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

12:06:42 [fantasai]

ed: issue 7 solved by issue 5

12:07:05 [fantasai]

ed: last one is about the list of attributes to promote

12:07:22 [fantasai]

ed: We're fine with the list as proposed

12:08:08 [fantasai]

Topic done.

12:08:24 [fantasai]

Switching over to CSS chairs

12:08:46 [fantasai]

Topic: Agenda

12:08:57 [fantasai]

Sylvain proposes Grid for 4pm tomorrow

12:09:04 [florianr]

florianr has left #fx

12:09:35 [florianr]

florianr has joined #fx

12:09:52 [fantasai]

Going to discuss transitions/animations/transforms now

12:10:16 [fantasai]

Topic: Transitions

12:10:22 [fantasai]

plinss: What's the status?

12:10:31 [fantasai]

dbaron: Transitions is waiting on someone to write up proposals for the hard issues

12:10:43 [fantasai]

dbaron: Went through most issues already. There were 4 issues that I categorized as hard

12:11:00 [fantasai]

dbaron: which meant I need to think about them more before writing a proposal. Or someone else does.

12:11:11 [fantasai]

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

12:11:13 [fantasai]

dbaron; right

12:11:19 [fantasai]

Florian: Any other issues?

12:11:33 [fantasai]

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

12:11:36 [sylvaing]

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

12:11:39 [fantasai]

dbaron: It's a pretty small number

12:11:47 [fantasai]

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

12:12:17 [fantasai]

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

12:12:43 [fantasai]

[wecanhaztechnicalproblems

12:12:44 [fantasai]

]

12:14:57 [fantasai]

dbaron: actually, there are some here with multiple proposals

12:15:15 [fantasai]

dbaron: Problem with 14608 is that there's no spec text

12:15:30 [fantasai]

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

12:15:49 [fantasai]

dbaron: 14615 ...

12:15:57 [fantasai]

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

12:16:03 [dbaron]

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

12:16:31 [fantasai]

dbaron: Question of what we want to do when you reverse a transition that's midway through

12:16:46 [fantasai]

dbaron: basic problem is, you say something like

12:16:55 [fantasai]

dbaron: p {transition: margin-left 1s; }

12:17:04 [fantasai]

dbaron: p:hover { margin-left: 100px; }

12:17:11 [fantasai]

dbaron: paragraph supposed to move over 1s 100px

12:17:24 [fantasai]

dbaron: Problem is if you move mouse out of paragraph 1/2 second in

12:17:35 [fantasai]

dbaron: don't want it to move back to where it was in .25s

12:17:42 [fantasai]

dbaron: not move at 1/4 the speed it moved in

12:18:05 [fantasai]

dbaron: gets more complicated with varying timing functions

12:18:13 [fantasai]

Florian: current implementations take 1s to go back?

12:18:29 [fantasai]

dbaron: Gecko never took 1s to took back. It implements my proposal, proposal in the issue

12:18:40 [fantasai]

dbaron: Dean proposed text above the issue, don't know if it was implemented

12:19:00 [fantasai]

dbaron: So, what the proposal in spec text says is,

12:19:08 [fantasai]

dbaron: That you detect that you're doing the opposite of what you just did

12:19:32 [fantasai]

dbaron: You detect that you're now transitioning to the value you were transitioning from

12:19:49 [fantasai]

:)

12:20:05 [fantasai]

dbaron: In that case, where you hit the reversing, you follow the exact reversing of what you've already done

12:20:15 [fantasai]

dbaron: That means essentially that you use the specified timing function backwards

12:20:27 [fantasai]

dbaron: Which means you're ignoring a specified timing function that's different for both directions

12:20:34 [fantasai]

birtles: ease-in vs. ease-out

12:20:45 [fantasai]

dbaron: You run only the piece of the function that you've already done.

12:20:51 [fantasai]

dbaron: This can create discontinuities.

12:21:05 [fantasai]

dbaron: If you move the mouse out at 99% completion, you do the reverse animation

12:21:20 [fantasai]

dbaron: if you move the mouse out at 100% completion, you run the forward animation in the other direction

12:22:16 [fantasai]

dbaron: What I implemented in Gecko, which I believe predates this text, was different

12:22:28 [fantasai]

dbaron: We use the timing function that's specified, but we shorten the time of the transition

12:22:42 [fantasai]

dbaron: based on how far it is, I believe, distance-wise, through its transition

12:22:54 [fantasai]

dbaron: if you interrupt the transition 25% timewise and 50% distancewise,

12:23:14 [fantasai]

dbaron: we run the transition as normal in the other direction, but multiply the duration at 50%

12:23:27 [fantasai]

dbaron: when I was doing this, I experimented with various possibilities

12:23:34 [fantasai]

dbaron: This was the only one that didn't look awful

12:24:15 [fantasai]

dbaron: One of these emails does say what things I experimented with

12:24:26 [fantasai]

glazou: What do you mean by ugly?

12:24:31 [fantasai]

dbaron: It just looked wrong to me?

12:24:36 [fantasai]

dbaron: I was doing animations of movement.

12:24:48 [fantasai]

dbaron: In a similar way to what Webkit does right now, going back slowly, feels wrong

12:24:55 [fantasai]

dbaron: the other experiments felt wrong

12:25:09 [fantasai]

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

12:25:17 [fantasai]

dbaron: The discontinuity is probably the biggest problem with it

12:25:30 [fantasai]

dbaron: Could also be wrong if you're expecting transition to ease at it's start

12:25:41 [fantasai]

dbaron: if you reverse it while you're in the fast part

12:25:46 [fantasai]

dbaron: I think I tried this... trying to remember

12:26:07 [glenn]

glenn has joined #fx

12:26:11 [fantasai]

dbaron: But may when look better if it compacts the timing function to ease into the reverse direction

12:26:36 [fantasai]

glazou: ...

12:26:39 [dbaron]

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

12:26:46 [fantasai]

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

12:26:54 [dbaron]

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

12:27:06 [fantasai]

vhardy: in SVG animations, you would actually have the second animation that [accumulates] the second one

12:27:09 [fantasai]

...

12:27:53 [fantasai]

vhardy: In an equivalent situation, instead of killing the first animation in the first one, you accumulate both

12:28:06 [fantasai]

vhardy: The first one runs its course, but the base value of the second animation [...]

12:28:38 [fantasai]

dbaron: sounds like that doesn't really reverse immediately

12:28:55 [fantasai]

dbaron: There's an aspect there of UI responsiveness

12:29:13 [fantasai]

dbaron: Want the user to feel like their action has done something, so want it to go in the other direction immediately

12:29:25 [fantasai]

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

12:29:35 [fantasai]

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

12:29:38 [vhardy_]

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

12:30:19 [fantasai]

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

12:31:03 [fantasai]

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

12:31:20 [fantasai]

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

12:31:42 [fantasai]

Florian: New property for controlling interrupted transitions?

12:32:32 [fantasai]

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

12:32:52 [fantasai]

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

12:33:04 [fantasai]

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

12:33:17 [fantasai]

Tab: Think we need demos

12:33:25 [fantasai]

plinss: So let's action someone to do that

12:33:47 [fantasai]

ACTION Tab: make demos

12:33:47 [trackbot]

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

12:34:25 [fantasai]

plinss: next issue

12:34:38 [fantasai]

plinss: previous issue

12:34:44 [dbaron]

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

12:34:52 [fantasai]

plinss: There seems to be a proposal there

12:35:05 [fantasai]

dbaron: we also implemented something with quaternians

12:35:10 [fantasai]

dbaron: is there spec text there?

12:35:20 [fantasai]

krit: we have exactly this in Transforms

12:35:42 [fantasai]

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

12:35:48 [fantasai]

plinss: third issues

12:35:57 [fantasai]

bug 14621

12:36:00 [dbaron]

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

12:36:24 [fantasai]

dbaron: question is, what do you do about mismatched lengths

12:37:00 [fantasai]

dbaron: What does webkit do here?

12:37:26 [fantasai]

dbaron: For backgrounds, ...

12:37:30 [fantasai]

plinss: what happens without a transition

12:37:31 [fantasai]

?

12:37:49 [fantasai]

dbaron: I implemented least common multiple interpolation of lists

12:38:04 [fantasai]

dbaron: The idea is, for a list that implicitly repeats, if you have mismatched length lists,

12:38:14 [fantasai]

dbaron: you find the least common multiple of list lengths

12:38:22 [fantasai]

dbaron: your interpolation result is a list of that length

12:38:46 [fantasai]

dbaron: For list types that repeat, that produces a smooth interpolation from one to the other

12:39:01 [fantasai]

Tab: repeating gradients do the same thing

12:39:14 [dbaron]

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

12:40:30 [fantasai]

dbaron: spec right now says they're not interpolable

12:40:36 [Zakim]

-Tav

12:41:08 [fantasai]

fantasai: is that a problem for level 3?

12:41:45 [fantasai]

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

12:42:13 [fantasai]

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

12:42:27 [fantasai]

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

12:42:40 [fantasai]

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

12:42:46 [fantasai]

bug 14723

12:42:47 [dbaron]

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

12:43:24 [fantasai]

Tab: The rule is, you don't kick a transition off from a transition

12:43:39 [fantasai]

Tab: even though transition change sthe computed value

12:43:48 [fantasai]

Tab: But if you have a value that depends on another value, e.g. em units

12:43:59 [fantasai]

Tab: That also changes the computed value, don't say whether that kicks of transitions

12:44:35 [fantasai]

dbaron: Proposed solution is, don't start an independent transition, but the transition of the thing that's animating causes the other thing to animate too

12:44:53 [fantasai]

dbaron: we all agree on how it shold work, just need to define it

12:45:04 [fantasai]

dbaron: I think we need a more general statement than what's there

12:45:54 [tabatkins__]

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

12:47:24 [fantasai]

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

12:47:59 [fantasai]

discussion of the implications of this

12:48:38 [dbaron]

dynamic change of font-size plus width: 10em

12:48:42 [dbaron]

compare:

12:48:50 [dbaron]

transition: font-size 2s, width 10s

12:48:52 [dbaron]

with:

12:48:55 [dbaron]

transition: width 10s

12:50:09 [dbaron]

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

12:51:36 [vhardy_]

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

12:52:57 [fantasai]

fantasai: Why are we transitioning the width at 10s in dbaron's second case?

12:53:18 [fantasai]

fantasai: the font size jumps. The width then slowly catches up??

12:54:59 [fantasai]

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

12:55:23 [fantasai]

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

12:56:00 [fantasai]

dbaron: That would make transitions very different

12:58:02 [fantasai]

plinss: In this example (rune's), you'll get a smooth transition

12:58:11 [fantasai]

plinss: if they transition at different rates, they transition at different rates

12:58:38 [fantasai]

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

12:59:37 [fantasai]

plinss: Shouldn't go backwards at any point

12:59:48 [fantasai]

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

13:00:09 [dbaron]

transition: font-size 10s, width 2s

13:00:09 [fantasai]

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

13:00:11 [dbaron]

is the bad one

13:00:16 [fantasai]

tab: You have to be smarter to get a sane result

13:00:29 [fantasai]

tab: When you're computed the end state for the width, you have to notice that font-size is also transitioning

13:00:38 [fantasai]

tab: you have to match up the font-size timeline

13:00:46 [fantasai]

tab: with the width timeline

13:01:07 [fantasai]

plinss: If you have two interdependent properties transitioning at the same time

13:01:26 [fantasai]

plinss: the end value of the short one has to be the partially-transitioned value of the long one

13:01:31 [jet]

jet has joined #fx

13:01:42 [fantasai]

plinss: that's what the author specified, so just do that

13:01:47 [fantasai]

dbaron: This is a horrible effect

13:01:49 [fantasai]

plinss: but they asked for it

13:02:22 [fantasai]

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

13:02:35 [fantasai]

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

13:02:42 [fantasai]

dbaron: It's hard to even detect this case

13:03:04 [fantasai]

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

13:03:25 [fantasai]

dbaron: you probably just want to use transforms to that

13:03:41 [fantasai]

dbaron: we're looking at something that would double the complexity of a transitions implementation

13:03:48 [fantasai]

dbaron: to implement Peter's proposal

13:04:13 [fantasai]

plinss: ok, let's back up

13:04:28 [fantasai]

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

13:04:32 [fantasai]

s

13:04:39 [fantasai]

plinss: So as long as the time is the same, start to end, it's one transition

13:04:48 [fantasai]

plinss: so we're agreeing on that

13:04:58 [fantasai]

shane: timing function ...

13:05:13 [fantasai]

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

13:05:19 [fantasai]

shane: webkit doesn't do that right now

13:05:26 [fantasai]

dbaron: You're transitioning in ems?

13:05:40 [fantasai]

shane: oh, I'm using percentages here

13:05:49 [fantasai]

dbaron: percentages are computed values; that's different

13:06:19 [fantasai]

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

13:06:49 [fantasai]

Tab: my text says that the font-size transition does not cause a separate transition, but rune's testcase explicitly changes the value of width

13:07:26 [fantasai]

Tab: If you look at the end value fo ryour width

13:07:41 [fantasai]

...

13:07:53 [fantasai]

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

13:08:01 [fantasai]

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

13:08:08 [fantasai]

dbaron: Yeah, we don't define simultaneity

13:08:25 [fantasai]

Tab: If you assume simultaneity...

13:08:33 [fantasai]

dbaron: Transitions are pretty dodgy. They just happen to work.

13:08:44 [fantasai]

dbaron: if people care about edge cases, they should use some other mechanism

13:09:26 [fantasai]

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

13:09:40 [fantasai]

dbaron: would break content

13:09:51 [fantasai]

dbaron: also we don't store cascaded values

13:10:09 [fantasai]

dbaron: would double or triple mem storage for properties

13:11:38 [fantasai]

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

13:11:41 [fantasai]

right now, no

13:12:01 [krit]

krit has joined #fx

13:12:11 [fantasai]

dbaron: My proposal is to leave the spec unchanged

13:12:15 [fantasai]

plinss: which means?

13:12:41 [fantasai]

Tab: yeah, I guess that would increase the complexity

13:12:50 [fantasai]

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

13:13:01 [fantasai]

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

13:13:55 [fantasai]

dbaron: I don't think sequential is the right thing.

13:14:06 [fantasai]

dbaron: I think both Gecko and Webkit do not match what the spec currently says

13:14:17 [fantasai]

dbaron: I don't know why Gecko doesn't

13:14:17 [Bert]

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

13:14:22 [fantasai]

plinss: what does Gecko do?

13:14:45 [fantasai]

dbaron: I think it's changing width at the end...

13:14:55 [fantasai]

dbaron: I think it's computing the transition on width, assuming the prior font size

13:15:05 [fantasai]

dbaron: I think this might've been intentional ...

13:15:23 [fantasai]

dbaron: I think we compute each property's transition assuming a cerain set of value for the other properties

13:15:32 [fantasai]

dbaron investigates

13:15:45 [fantasai]

szilles: Sounds like one possible interpretation of simultaneous transitions..

13:15:58 [fantasai]

szilles: I would prefer it be undefined until someone shows a use case where it would be useful

13:17:07 [fantasai]

dbaron: oh! rune's testcase is not what I thought it was

13:17:16 [fantasai]

dbaron: I know why Gecko behaves the way it does now

13:17:34 [fantasai]

dbaron: So basically, I didn't quite implement literally what the spec says,

13:17:57 [fantasai]

dbaron: you block the effect of an inherited transition on an element you're transitioning on

13:18:09 [fantasai]

dbaron: but [...]

13:18:21 [fantasai]

dbaron: but I do that for everything at once

13:18:35 [fantasai]

dbaron: So Gecko would behave differently here if the width were on #outer

13:19:00 [fantasai]

dbaron: Because the font-size is inherited, it's ignoring it because it's an animation on an inherited property

13:19:13 [fantasai]

dbaron: It's transitioning the width from 50px to 100px

13:19:22 [fantasai]

dbaron: And then it jumps at the end to 300px

13:19:28 [Cyril_]

Cyril_ has joined #fx

13:19:35 [fantasai]

plinss: you're not computing inheritance during the transition

13:20:04 [fantasai]

dbaron: We're saying, we started a transition on font-size. Now need to figure out whether we need to start transitions on descendants

13:20:12 [fantasai]

dbaron: Let's block the inheritance effect ..

13:20:20 [fantasai]

dbaron: But we start the wrong transition for width as a result

13:20:29 [fantasai]

dbaron: But it's not a bug I can fix in any remotely performant way

13:20:56 [fantasai]

dbaron: Would need to redo style resolution through the whole subtree

13:21:14 [fantasai]

Tab: I understand the jumpiness and how to explain it

13:22:28 [fantasai]

Tab: dbaron's way is well-defined and cheap

13:22:33 [fantasai]

dbaron: But it does behave badly in this case

13:22:42 [fantasai]

dbaron And rune's testcase is a reasonable testcase

13:23:29 [fantasai]

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

13:23:42 [fantasai]

dbaron: I think you could get rune's testcase to work by following the spec

13:23:50 [fantasai]

dbaron: but would still be weird if you gave different times

13:24:04 [fantasai]

dbaron: font-size 2s, width 10s

13:24:16 [fantasai]

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

13:24:45 [fantasai]

...

13:24:50 [fantasai]

dbaron: Talking about keeping spec as it is

13:25:04 [fantasai]

dbaron: Talks about skipping a transition if change is due to inheritance

13:25:29 [fantasai]

Tab thinks that's cool

13:25:34 [fantasai]

szilles is confused

13:25:50 [fantasai]

szilles: If I start a transition whenver it changes, would I get multiple starts as I go through the higher-level change?

13:26:09 [fantasai]

szilles: I'm changing font-size on the outer, and for each change in font size I trigger a new transition in width. Don't I?

13:26:29 [fantasai]

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

13:26:35 [fantasai]

Tab: thought that was what I said

13:26:47 [fantasai]

dbaron: No, another rule. Applies to CSS animations and SMIL, etc.

13:27:22 [fantasai]

...

13:27:28 [fantasai]

dbaron: Some of this depends on your mental model

13:27:46 [fantasai]

dbaron: Are you processing the transition on the parent before you compute on the children or not

13:28:10 [fantasai]

szilles: ...

13:28:19 [fantasai]

dbaron: future points in time not a problem

13:28:46 [fantasai]

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

13:28:57 [fantasai]

dbaron: There's one problem, which is what Steve says,

13:29:11 [fantasai]

dbaron: We put this text in the spec because nothing defines the model of doing style resolution.

13:29:48 [fantasai]

dbaron: I think we do need to add text to the spec to say that implementations do start a resolution if there was a change inherited from an ancestor on a different property.

13:30:00 [fantasai]

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

13:30:10 [fantasai]

szilles: I'd be happy not allowing that case

13:30:15 [fantasai]

dbaron: Problem is detecting that case.

13:30:34 [fantasai]

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

13:31:00 [fantasai]

plinss: So, do we have a conclusion?

13:31:05 [fantasai]

dbaron: I can try to write proposed text.

13:31:14 [fantasai]

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

13:31:24 [fantasai]

ACTION dbaron: write proposed text for this discussion

13:31:24 [trackbot]

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

13:33:36 [fantasai]

discussion of transitioning in premultiplied space

13:33:44 [fantasai]

RESOLVED: transition colors in premultiplied space

13:34:06 [fantasai]

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

13:34:06 [trackbot]

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

13:37:01 [fantasai]

ted: there was some reason for it being floor

13:37:36 [birtles]

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

13:37:37 [birtles]

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

13:38:09 [fantasai]

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

13:39:22 [fantasai]

some discussion between shane and Bert on this

13:39:46 [fantasai]

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

13:39:59 [fantasai]

proposed to make it round(), for consistency

13:40:16 [fantasai]

RESOLVED: copy SMIL's rounding of numbers to integers

13:40:59 [fantasai]

cubic-bezier

13:41:15 [fantasai]

dbaron: We allow cubic-bezier with y values outside the allowed range

13:41:43 [fantasai]

dbaron: which means the value can be outside the allowed range of the property; since we usually check for that at parse time

13:42:09 [fantasai]

dbaron: proposal is to clamp within range, e.g. while width is pushed below zero, it's treated at zero

13:42:12 [fantasai]

s/at/as/

13:42:45 [fantasai]

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

13:43:27 [fantasai]

Tab: what's marker-offset

13:43:57 [fantasai]

dbaron: was in CSS2.1 and maybe CSS3 Lists

13:44:04 [fantasai]

Tab: Definitely not in CSS3 Lists

13:44:08 [fantasai]

s/2.1/2.0/

13:44:37 [fantasai]

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

13:44:53 [fantasai]

dbaron: Could leave transform to the Transforms spec

13:44:59 [fantasai]

dbaron: Don't think that spec has the Animatable lines

13:46:08 [fantasai]

fantasai: background/border-radius/box-shadow are defined in css3-background already

13:46:18 [fantasai]

fantasai: suggest having css3-fonts handle font-

13:46:26 [fantasai]

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

13:46:36 [fantasai]

plinss: so not adding to this spec

13:48:01 [fantasai]

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

13:48:11 [fantasai]

plinss: add them, but add them at-risk

13:48:20 [fantasai]

plinss: until there's 2 implementations

13:48:54 [fantasai]

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

13:49:01 [fantasai]

(rest go intheir respective modules)

13:49:10 [fantasai]

<break duration=15m>

13:49:22 [Bert]

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

13:52:04 [shanestephens]

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

13:53:35 [arronei_]

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

13:58:34 [plinss]

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

13:58:57 [plinss]

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

13:59:02 [arronei_]

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

13:59:17 [plinss]

oh, you're missing something alright...

13:59:20 [glazou]

glazou has joined #fx

13:59:40 [arronei_]

plinss: yeah I know I wish I was there. or maybe I don't :)

14:08:09 [AlexD]

AlexD has joined #fx

14:09:15 [fantasai]

Topic: Transforms

14:10:15 [fantasai]

bug 14715 - clarify interopolation of some transform functions

14:10:28 [fantasai]

krit: some concerns on the list

14:10:41 [fantasai]

krit: say that transforms of same type can be interpolated

14:10:47 [fantasai]

krit: added new section for that

14:10:52 [fantasai]

krit: I think this bug is closed

14:11:12 [fantasai]

krit: left open in case someon thinks it's not fixed

14:11:55 [dbaron]

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

14:11:58 [sylvaing]

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

14:12:40 [fantasai]

krit explains what's in the spec

14:13:19 [fantasai]

dbaron: there's 2 possible ways to animate a skew

14:13:31 [fantasai]

dbaron: You could animate as angle or as shear

14:14:28 [fantasai]

krit: animate as angle right now

14:14:41 [fantasai]

dbaron: interpolation rules should be in terms of computed values

14:14:56 [fantasai]

dbaron: And computed values convert <length>s to a common unit

14:16:51 [fantasai]

fantasai: unit could be anything

14:17:00 [fantasai]

fantasai: although return values in the DOM are required to be in px

14:17:56 [Cyril]

Cyril has joined #fx

14:18:06 [fantasai]

fantasai: summary is, there's a new section in the spec. People should review the new section. Who is volunteering to review the new section?

14:18:18 [fantasai]

Tab: I'll review

14:18:36 [fantasai]

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

14:18:49 [krit]

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

14:19:12 [fantasai]

krit: wanted to have some kind of fallback for UAs that don't support 3D transformations

14:19:25 [fantasai]

krit: This section defines the 2D subset and specifies what to do if you don't support 3D

14:20:39 [fantasai]

dbaron: simplification of [...] for 2D cases is not that simple

14:21:14 [fantasai]

dbaron: the interpolation code that's referenced there will produce a 3D component in some cases

14:21:29 [fantasai]

dbaron: in any case where the ? produces a change in sign between origin and destination

14:21:34 [florianr]

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

14:21:40 [dbaron]

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

14:22:18 [fantasai]

krit: For Webkit, we try to flatten 4D transforms. This is done by ... all values

14:22:27 [fantasai]

krit: agree it's not the best way

14:22:36 [fantasai]

krit: Current spec says you don't support 3D functions at all

14:22:44 [fantasai]

dbaron: 2D and 3D specs used to be different

14:23:02 [fantasai]

dbaron: ... is wrong, because simplifying for 2D case is a nontrivial case

14:23:10 [fantasai]

dbaron: So you should say explicitly what happens there

14:23:21 [fantasai]

dbaron: b/c Webkit shipped for multiple years with a 2D case that was wrong

14:24:20 [fantasai]

fantasai: take this to the mailing list?

14:24:43 [fantasai]

krit: any volunteers to review?

14:24:51 [fantasai]

fantasai: I think dbaron just volunteered :)

14:25:51 [fantasai]

bug 15605

14:26:29 [fantasai]

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

14:26:54 [fantasai]

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

14:27:05 [fantasai]

dbaron: is this formulated as a question?

14:27:48 [fantasai]

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

14:29:08 [fantasai]

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

14:29:30 [fantasai]

Liam: If w is zero, then don't proceed.

14:29:38 [fantasai]

Liam: Your universe is collapsed

14:29:53 [fantasai]

Liam: either you don't render the thing, or it's an error

14:30:39 [fantasai]

deferred to the experts not here

14:30:45 [fantasai]

bug 15709

14:30:53 [Zakim]

- +1.732.216.aabb

14:31:09 [fantasai]

Ted: Aryeh was writing some test where the result in different implementations was the same modulo some amount of rounding

14:31:25 [fantasai]

Ted: It made him unhappy when the tests were passing where there was a difference of some amount

14:31:34 [fantasai]

Ted: don't think this is a Transforms issue

14:31:46 [fantasai]

Tab: Should be out-of-scope for this spec

14:31:58 [fantasai]

Tab: don't know how to address it

14:32:16 [dbaron]

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

14:32:37 [fantasai]

:)

14:33:09 [fantasai]

next is 15871

14:33:15 [sylvaing]

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

14:33:40 [fantasai]

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

14:33:58 [fantasai]

Tab: So in the normal case, where everything's flattened,

14:34:19 [fantasai]

Tab: If you have element with 2 children, one is z-translated above, another z-translated below

14:34:39 [fantasai]

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

14:34:49 [fantasai]

dbaron: expensive to assume you want it on everything

14:35:06 [fantasai]

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

14:35:18 [fantasai]

Tab: Yes, you tell implementations when you want the expensive path

14:35:30 [fantasai]

Tab: you have to track a bunch of stuff, and that slows things down

14:35:41 [fantasai]

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

14:35:43 [cabanier]

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

14:35:54 [Zakim]

disconnecting the lone participant, +49.403.063.68.aaaa, in Team_(fx)11:32Z

14:35:56 [fantasai]

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

14:35:56 [Zakim]

Team_(fx)11:32Z has ended

14:35:56 [Zakim]

Attendees were +49.403.063.68.aaaa, Tav, +1.732.216.aabb

14:36:46 [fantasai]

?: It makes sense that opacity flattens things

14:37:25 [plinss]

zakim, room for 5?

14:37:27 [fantasai]

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

14:37:27 [Zakim]

ok, plinss; conference Team_(fx)14:37Z scheduled with code 26632 (CONF2) for 60 minutes until 1537Z; however, please note that capacity is now overbooked

14:37:35 [Zakim]

Team_(fx)14:37Z has now started

14:37:40 [cabanier]

? is me

14:37:44 [Zakim]

+ +49.403.063.68.aaaa

14:38:03 [fantasai]

plinss: so where are we at?

14:38:47 [fantasai]

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

14:39:10 [fantasai]

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

14:39:14 [fantasai]

Ted: I really hope so

14:39:23 [fantasai]

Bert: what does that mean?

14:41:00 [fantasai]

Tab: So we don't flatten with opacity

14:44:22 [fantasai]

Tab: We inherit opacity into the children instead of doing group opacity, that's why it works

14:44:28 [fantasai]

plinss: That's not what we want

14:44:36 [fantasai]

plinss: sounds like we want application of opacity flattens it

14:45:05 [fantasai]

plinss: What if we then add controls to do group opacity or not?

14:45:20 [fantasai]

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

14:45:47 [fantasai]

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

14:46:15 [fantasai]

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

14:47:42 [fantasai]

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

14:48:24 [fantasai]

Tab explains what preserve-3d means

14:51:54 [fantasai]

ACTION hober: review wording of flatting cases to make sure all are covered, and whether should be property-by-property or generic wrt Appendix E

14:51:54 [trackbot]

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

14:51:58 [krit]

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

14:54:02 [fantasai]

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

14:54:17 [fantasai]

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

14:54:59 [fantasai]

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

14:55:06 [fantasai]

Tab: So you need to specify the units.

14:55:54 [krit]

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

14:56:27 [fantasai]

krit: everyone on the mailing list agreed on using quaternians

14:56:57 [fantasai]

krit: I suggest to do that, and to use code from Firefox

14:57:18 [krit]

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

14:58:15 [tabatkins__]

hober: Are there significant behavior differences?

14:58:40 [cabanier]

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

14:59:00 [tabatkins__]

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

14:59:24 [krit]

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

15:00:07 [fantasai]

RESOLVED: Use quaternians for rotation by translating Firefox's implementation to spec pseudo-code

15:02:39 [krit]

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

15:03:52 [fantasai]

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

15:03:57 [fantasai]

krit: ...

15:04:06 [fantasai]

krit: It's not really defined how the line should look like

15:04:09 [dbaron]

s/quaternians/quaternions/

15:04:11 [fantasai]

krit: is it a point or infinite line

15:04:22 [dbaron]

something about non-scaling stroke

15:04:41 [fantasai]

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

15:04:44 [fantasai]

??

15:04:49 [fantasai]

krit: imagine you have a rect

15:04:52 [fantasai]

krit: and you apply a scale

15:04:58 [fantasai]

krit: the border of the rect gets scaled as well

15:05:07 [fantasai]

krit: scale(2) makes it twice as big

15:05:28 [fantasai]

krit: there's a property that allows not scaling the stroke

15:06:00 [fantasai]

krit: when the element is skewed to zero height, what do you draw

15:07:14 [fantasai]

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

15:08:33 [fantasai]

fantasai: so if you scale to zero height, do you see the line segment?

15:08:42 [fantasai]

fantasai: skew can make an infinite line, so not render?

15:09:53 [fantasai]

Liam: This was a problem in PostScript, you'd get infinite lines that seem to come from no reason

15:10:05 [fantasai]

Liam: Better to vanish from the screen than to fill it

15:10:46 [fantasai]

Liam: With PostScript we ended up with miter-limit and stuff like that

15:11:03 [fantasai]

krit: choice of ignore transform, or not render

15:11:08 [fantasai]

krit: for SVG we not render

15:12:01 [fantasai]

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

15:13:59 [fantasai]

szilles: easier for user to understand if they all disappear

15:14:19 [fantasai]

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

15:15:23 [fantasai]

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

15:15:50 [fantasai]

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

15:16:34 [Liam]

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

15:16:52 [fantasai]

...

15:17:02 [fantasai]

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

15:17:38 [fantasai]

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

15:17:43 [fantasai]

fantasai: if it has a border, you see it

15:17:56 [fantasai]

krit: ...

15:18:14 [fantasai]

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

15:18:21 [fantasai]

vhardy: Which scale?

15:18:29 [fantasai]

vhardy: 3D context can be anywhere

15:18:34 [smfr]

smfr has joined #fx

15:18:41 [fantasai]

vhardy: How do you extract what scale factor to handle?

15:18:53 [fantasai]

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

15:18:59 [fantasai]

vhardy: It only shows up for 3D transforms

15:19:07 [fantasai]

vhardy: You have a perspective in 3D, right

15:19:25 [fantasai]

vhardy: Ideally, your geometry would be transformed in 3D and then you'd stroke that.

15:19:43 [fantasai]

vhardy: That's different from 2D, where you can compute your geometry .. and then stroke like you want on the object

15:19:56 [fantasai]

vhardy: It's very simply described

15:20:02 [fantasai]

vhardy: Think of stroking as computing another shape

15:20:14 [fantasai]

vhardy: You can either get your geometry and then transform it

15:20:22 [fantasai]

vhardy: or transform the outline first, then compute the stroke outline

15:20:31 [fantasai]

vhardy: libraries don't allow you to do that

15:21:01 [fantasai]

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

15:21:08 [fantasai]

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

15:21:21 [fantasai]

vhardy: Either disable non-scaling stroke altogether on 3D transforms

15:21:30 [fantasai]

vhardy: or specify how you'd extract the scaled parameters

15:22:11 [fantasai]

tabatkins__: if you just translateZ it you change the size...

15:22:36 [fantasai]

tabatkins__: let's turn it off in all cases

15:23:45 [fantasai]

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

15:24:11 [fantasai]

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

15:24:40 [fantasai]

RESOLVED: as Tab proposed

15:24:59 [fantasai]

RESOLVED: Don't render if the transform is singular

15:25:18 [krit]

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

15:25:35 [fantasai]

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

15:25:46 [fantasai]

Tab: correct; it's an invertible matrix

15:25:56 [fantasai]

krit: some issues in source code

15:26:26 [fantasai]

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

15:26:46 [smfr]

i'm with Tab

15:26:52 [smfr]

those comments were never intended for WG discussion

15:27:05 [smfr]

editors can resolve or make issues as necessary

15:27:30 [fantasai]

ACTION smfr: sift through comments in transforms spec, turn into issues or delete as appropriate

15:27:30 [trackbot]

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

15:27:36 [fantasai]

Topic: Animations

15:28:17 [sylvaing]

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

15:29:06 [fantasai]

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

15:29:10 [fantasai]

er

15:29:21 [fantasai]

sylvaing: Lea suggested adding reverse

15:29:26 [fantasai]

sylvaing: and then alternate-reverse

15:29:34 [fantasai]

sylvaing: Now that we have all these values, she has two proposals

15:29:44 [fantasai]

sylvaing: One was to change the syntax of this one, it would take

15:30:04 [fantasai]

sylvaing: animation-direction: normal | alternate || reverse

15:30:11 [fantasai]

sylvaing: wouldn't need to remember which is first

15:30:21 [fantasai]

sylvaing: next one she proposed is redefining the feature as a new property

15:30:38 [fantasai]

sylvaing: instead of thinking of it as direction of animation, think of which iterations are reversing

15:30:46 [fantasai]

animation-reverse: none | all | even | odd

15:31:01 [fantasai]

confusion over 0-based or 1-based counting

15:31:14 [fantasai]

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

15:31:21 [fantasai]

sylvaing: Lots of websites using animation-direction

15:31:40 [fantasai]

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

15:33:09 [fantasai]

fantasai agrees with Florian and Tab

15:33:24 [fantasai]

fantasai: I agree with Lea on the reorderable alternate-reverse syntax, though

15:33:37 [fantasai]

fantasai: Would also suggest s/normal/forward/ which matches css3-marquee

15:33:49 [fantasai]

dbaron: Another item in the shorthand uses forwards/backwards

15:33:56 [vhardy_]

vhardy: I like the animation-reverse proposal

15:35:13 [fantasai]

sylvaing: are we saying no to animation-reverse?

15:35:20 [fantasai]

dbaron: Yeah, because of even/odd problem

15:35:27 [fantasai]

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

15:35:43 [fantasai]

dbaron: maybe, but it's also an issue of this going into the shorthand

15:36:33 [fantasai]

dbaron: for splitting alternate-reverse, I think it's more confusing for the shorthand

15:37:14 [fantasai]

dbaron: prefer to keep as one keyword so you think of it as one thing

15:37:30 [fantasai]

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

15:37:36 [fantasai]

fantasai: nooooo

15:37:56 [fantasai]

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

15:38:05 [dbaron]

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

15:38:16 [fantasai]

vhardy: ...

15:38:31 [fantasai]

Tab: Spec's descriptions rely on 0-indexing

15:38:56 [fantasai]

dbaron: that description is 1-based

15:39:07 [fantasai]

dbaron: I write prose 1-based and code 0-based

15:39:38 [fantasai]

Tab: Right, I read that wrong.

15:39:58 [fantasai]

RESOLVED: no change to animation-direction syntax

15:40:46 [smfr]

yay

15:41:58 [smfr]

to-and-fro, fro-and-to

15:42:01 [Zakim]

disconnecting the lone participant, +49.403.063.68.aaaa, in Team_(fx)14:37Z

15:42:03 [Zakim]

Team_(fx)14:37Z has ended

15:42:03 [Zakim]

Attendees were +49.403.063.68.aaaa

15:42:17 [sylvaing]

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

15:43:45 [fantasai]

sylvaing: so which properties do we snapshot, exactly?

15:44:00 [dbaron]

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

15:44:25 [fantasai]

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

15:44:51 [fantasai]

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

15:45:20 [fantasai]

sylvaing: could defer from L3

15:45:26 [smfr]

fantasai: on what topic?

15:45:32 [fantasai]

dbaron: Don't have implementations on the current spec

15:45:38 [fantasai]

smfr, snapshotting properties

15:45:41 [smfr]

ah right

15:45:45 [fantasai]

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

15:45:54 [fantasai]

dbaron: concerned about simultaneity

15:46:03 [fantasai]

dbaron: prefer to snapshot as little as possible

15:46:10 [fantasai]

dbaron: implementations coalesce a lot, and that can vary

15:46:18 [fantasai]

vhardy: work that remains to be done...

15:46:24 [fantasai]

dbaron: agreeing on exactly what to snapshot

15:46:28 [smfr]

i'm happy to finesse that

15:46:31 [fantasai]

birtles: ok with things jumping?

15:46:44 [smfr]

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

15:47:54 [fantasai]

ACTION smfr: make a list of snapshotting properties for animations

15:47:54 [trackbot]

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

15:48:03 [smfr]

hey no fair!

15:48:06 [fantasai]

ACTION dbaron: Make a list of snapshotting properties for animations

15:48:07 [trackbot]

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

15:48:22 [fantasai]

ACTION dbaron: talk with smfr about converging on snapshotted properties list

15:48:22 [trackbot]

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

15:48:23 [sylvaing]

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

15:48:45 [smfr]

sylvaing: i don't really have an opinion

15:49:04 [fantasai]

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

15:49:30 [sylvaing]

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

15:50:51 [fantasai]

dbaron: hard to get transitions and animations at same time [...]

15:51:06 [fantasai]

dbaron: if the animation starts changing the property immediately, because it's an animation-caused style change

15:51:12 [fantasai]

Tab: delay?

15:51:16 [fantasai]

dbaron: Delay would let transition start

15:51:23 [fantasai]

dbaron: Transitions operate on computed values

15:51:31 [fantasai]

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

15:51:37 [fantasai]

dbaron: Then it would not trigger a style change

15:51:40 [fantasai]

dbaron: well....

15:51:50 [fantasai]

dbaron: if there were some othe rsimultaneous change to the property, it would

15:51:56 [fantasai]

dbaron: we'd transition on that, ignoring the animation

15:52:06 [smfr]

don't you people have beer to drink?

15:52:13 [fantasai]

dbaron: seems to me the idea of transitions is you're taking a change that already happened

15:52:30 [fantasai]

dbaron: and you're saying you want to transition between them

15:52:34 [fantasai]

dbaron: it's almost on top of the cascade

15:52:53 [fantasai]

dbaron: we'd start a transition, but that transition wouldn't win? but that seemed really weird

15:53:11 [fantasai]

dbaron: that's why I put transitions at the top

15:53:18 [fantasai]

dbaron: Transitions override animations in Gecko

15:53:32 [fantasai]

dbaron: animations need to be lower, because they let you actually specify a value

15:53:47 [fantasai]

dbaron: You want say, a user stylesheet that says !important, not to be overrideable by an animation

15:54:02 [fantasai]

sylvaing: we put them at the override level at some point in our discussions

15:54:09 [fantasai]

sylvaing: but override level is still ...

15:54:32 [fantasai]

sylvaing: an animation running at the override level will still run over transition, right?

15:55:03 [fantasai]

dbaron: not in Gecko

15:55:17 [fantasai]

sylvaing: so transitions win, what happens to animation?

15:55:26 [fantasai]

dbaron: then the animation will resume when the transition finishes

15:55:34 [fantasai]

sylvaing: it resumes at that point in its timeline?

15:56:34 [fantasai]

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

15:56:52 [fantasai]

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

15:57:16 [fantasai]

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

15:58:11 [dbaron]

Gecko's cascade is currently:

15:58:13 [dbaron]

// Cascading order:

15:58:13 [dbaron]

// [least important]

15:58:13 [dbaron]

// -. UA normal rules = Agent normal

15:58:13 [dbaron]

// -. User normal rules = User normal

15:58:13 [dbaron]

// -. Presentation hints = PresHint normal

15:58:14 [dbaron]

// -. Author normal rules = Document normal

15:58:16 [dbaron]

// -. Override normal rules = Override normal

15:58:18 [dbaron]

// -. Author !important rules = Document !important

15:58:20 [dbaron]

// -. Override !important rules = Override !important

15:58:23 [dbaron]

// -. animation rules = Animation normal

15:58:25 [dbaron]

// -. User !important rules = User !important

15:58:26 [dbaron]

// -. UA !important rules = Agent !important

15:58:28 [dbaron]

// -. transition rules = Transition normal

15:58:30 [dbaron]

// [most important]

15:58:35 [fantasai]

trying to figure out cases where they'd interact

15:59:06 [fantasai]

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

15:59:51 [fantasai]

sylvaing: we don't have that in L3

16:01:38 [fantasai]

fantasai: if I have a property that's animating, and I hover over it and that changes to a different value, does it transition?

16:01:46 [fantasai]

fantasai: or is the transition suppressed because it's animating?

16:01:59 [fantasai]

fantasai: e.g. animating color between blue and green, on hover specify red

16:02:52 [fantasai]

various conversations...

16:03:03 [fantasai]

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

16:03:07 [fantasai]

krit: animations override transitions

16:03:16 [fantasai]

dbaron: let me write a testcase here...

16:04:12 [smfr]

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

16:04:24 [smfr]

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

16:06:41 [fantasai]

fantasai: So let's take my button example, suppose the base state is yellow, but it's in an animating state that varies between blue and green

16:06:46 [fantasai]

fantasai: the hover state is red

16:06:57 [fantasai]

fantasai: let's suppose a transition does get triggered, what colors does it go between?

16:07:04 [fantasai]

Florian: whatever color it's at to red

16:07:06 [fantasai]

e.g. teal to red

16:07:18 [fantasai]

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

16:07:24 [krit]

http://pastebin.com/BDfVLU4W

16:07:25 [fantasai]

fantasai: what color do I transition to?

16:07:36 [fantasai]

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

16:07:51 [fantasai]

fantasai: so I line up the timelines, say the transition is 2s, right now the color is teal so I start at teal

16:08:00 [fantasai]

fantasai: and I find the color at 2s into the animation, say it's orange

16:08:08 [fantasai]

fantasai: and animate between teal and orange

16:08:12 [fantasai]

fantasai: That seems to make sense

16:08:21 [fantasai]

fantasai: don't know how hard it would be to implement, but it makes sense.

16:08:23 [dbaron]

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

16:09:46 [fantasai]

Meeting closed.

16:10:08 [shanestephens]

shanestephens has joined #fx

16:10:28 [smfr]

smfr has left #fx

16:10:38 [jet]

jet has joined #fx

16:19:05 [kennyluck]

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

16:21:36 [dbaron]

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

16:21:45 [dbaron]

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

16:21:52 [dbaron]

(today was joint CSS/SVG)

16:22:07 [kennyluck]

dbaron, oh ok. Thank!

18:04:31 [Zakim]

Zakim has left #fx