Re: [css-properties-values-api] Transitions and custom properties

On Thu, Aug 27, 2015 at 3:37 AM François REMY <francois.remy.dev@outlook.com>
wrote:

> 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.
>

A very important point to make here is that multiple browser vendors are
*not* interested in speccing and shipping the world in one go. Houdini is
necessarily going to have to be incremental - we are strictly going to be
choosing the individually most impactful features for each level.

On the other hand, thinking about future features is important and useful.
So I'm glad we know we need a computeHook at a future level, but it
definitely can't be part of level 1.

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;
> }
>

These use cases would be best solved by allowing the registration of custom
shorthands. Implementation-wise, shorthands are dealt with long before
computation, and Houdini should expose a similar mechanic.


> 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.
>

Agreed, it's a valid use case. I think it can wait for a later level though.


> 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.
>

Could you provide use cases for this? In Sydney we spoke about custom types
with custom animators that I think might address what you want, but I'm not
sure.


> *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.
>

Can you describe what specific concerns you have so we can discuss them?

Cheers,
    -Shane


>
>
>
> *De :* Shane Stephens <shans@google.com>
> *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
>