- From: François REMY <francois.remy.dev@outlook.com>
- Date: Wed, 26 Aug 2015 17:19:59 +0000
- To: Shane Stephens <shans@google.com>, "public-houdini@w3.org" <public-houdini@w3.org>
- Message-ID: <DUB408-EAS40529B716B7B9BA345E0369A5600@phx.gbl>
So, if I understand correctly, your point is that the “ComputationHook” should be able to deal with the issues I had with the “ApplyHook” (except animated layouts which you feel should be handled using javascript; fair point). My initial impression is that it’s possible, though the fact that this won’t ship at the same time as the ApplyHook worries me. Just to be sure, could someone address this use case, which is one of those I presented at the time: … { --border: 5px solid green; } …:hover { --border-width: 10px; } and … { --border-width: 5px; --border… solid… green; } …:hover { --border: 10px solid red; } To solve this kind of problem, I was hoping to be able to use the StyleTransitionController but if this has to be dealt with by the browser, I guess this will require some more work in the spec. I think this is a quite valid use case, as almost all specs feature this kind of shorthand/longhand pairs. There are even multiple levels of this thing in the css grid spec, on which I’ve been working. Best regards, François PS: While I understand the reasoning, the combination of the ComputationHook and the ApplyHook won’t allow to create custom transitions or transitions between complex values, except if we allow cyclic property rewriting in ComputationHook. That still means we will end up with a variety of hooks to possibly try to match the feature set of a hook that’s better suited for the task, I’m afraid. But if that makes things easier to implement for browser agents, that may be an acceptable tradeoff. PS2: I’m still not happy with the way the interaction between polyfills is dealt by the specification, but I think this is one of the things on the agenda for the meeting, so I’ll wait to see what comes out of the discussions at that time. De : Shane Stephens Envoyé : mercredi 26 août 2015 18:05 À : public-houdini@w3.org Tab Atkins, Matt Rakow, and I worked through some use cases for mixing transitions and custom properties together, with an aim to identify the order in which transitions and the apply hook should be invoked. tl;dr: transitions should operate *before* the apply hook. Here are the use cases we looked at: (1) I want to transition my number-like custom property directly. (e.g. I have a --lighten property that modifies the output background-color by a percentage. I want to transition the amount by which things are lightened): .foo { --lighten: 5%; background-color: red; transition: --lighten 1s; } .foo:hover { --lighten: 25%; } If the transition runs first, then this just works: the transition creates intermediate values for --lighten, which are subsequently used to modify the background-color in apply(). If the transition runs after apply, though, then --lighten isn't updated until after it's written the background-color and we don't see a transition. Indeed, we'd have to transition background-color to see an effect, and that's *weird*. (2) I want to transition my property but have the effect of a custom property still apply: .foo { --lighten: 5%; background-color: red; transition: background-color 1s; } .foo:hover { background-color: green; } If the transition runs first, then background-color gets updated before apply hooks are run. Because --lighten has registered background-color as an input, it gets invoked and fixes up the background-color as required. If the apply hook runs first, then it will apply to the background-color which will then be transitioned. This works fine, but only as long as the apply hook is a linear transformation. (Actually, there might be a use case for explicitly wanting a linear transition between the output of a non-linear transformation, rather than transitioning in the linear space and applying the non-linearity at each point. I'd like to hear from anyone who can think of one). (3) I want to invent transition behavior between two names (effectively, I want to generate custom aliases): .foo { --color: chartrurple; transition: --color 1s; } .foo:hover { --color: beiglemousse; } If the transition runs first, this won't work. There's no way to transition between these names directly. If the apply hook runs first, this won't work. It's not --color that would need to transition, but whatever property this actually applies to. As mentioned above, that would be weird. Fortunately, we know that we want to introduce a custom computation phase in a future level of the specification, and that would be an *excellent* way to implement aliases. (4) I want my custom property to generate transitioning behavior without explicit requests from the author - e.g. this would transition over a period of time *in the absence of any transition: value being set*: .foo { --lighten: 5%; } .foo:hover { --lighten: 25%; } Please don't do that :) It's effectively a form of working against author intent. -------- Any other use cases or suggestions welcome, but at the moment it's looking like transition followed by apply is the right way to go. Cheers, -Shane
Received on Wednesday, 26 August 2015 17:37:39 UTC