Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

applyStyles doesn't affect initialComputedStyle #78

Closed
samselikoff opened this issue Mar 12, 2019 · 1 comment
Closed

applyStyles doesn't affect initialComputedStyle #78

samselikoff opened this issue Mar 12, 2019 · 1 comment

Comments

@samselikoff
Copy link
Contributor

samselikoff commented Mar 12, 2019

I think I might be misunderstanding the intended use for applyStyles

let sprite = insertedSprites[0];

console.log(sprite.initialComputedStyle); // null

sprite.applyStyles({
  opacity: '0.5'
});

console.log(sprite.initialComputedStyle); // null

Is there a general way to set/update the initialComputedStyle for a Sprite? I noticed some methods like startAtSprite affect it.

In general I'm having trouble using applyStyles throughout my transition, but I think my mental model for it might be off. I would expect to be able to do something like

sprite.applyStyles({
  opacity: '0.5'
});

adjustCSS('opacity', sprite);

and have it fade in.

@ef4
Copy link
Contributor

ef4 commented Mar 12, 2019

Yes, we should clarify the mental model because it's not what you're describing.

initialComputedStyle and finalComputedStyle are not things we are free to change. They're supposed to reflect the true state of the app before and after the animation, and animations are not allowed to alter that.

applyStyles always take temporary effect. It can apply whatever it wants to, but that only matters during the animation, and at the end we will still go back to whatever we were going to have if there had been no animation at all.

It's fine to use applyStyles at the start of a transition, but that's still inside the transition. You aren't altering the initialComputedStyle, because that measures the world before there was any transition at all.

Motions really shouldn't try to measure anything about the DOM, including computed styles. Firstly because they can't accurately because what they see is being tainted by other motions. And second because it's easy to accidentally cause layout thrashing if motions are both reading and writing DOM. So a motion like adjustCSS isn't looking at the current state of the Element to decide a start point, it's looking at initialComputedStyle and finalComputedStyle, which the library has already measured for us at the points in time where those things are actually measurable.

The better way to say:

sprite.applyStyles({
  opacity: '0.5'
});
adjustCSS('opacity', sprite);

would be to improve adjustCSS so it takes an optional initial value argument that overrides the measured one:

// proposed API, not implemented
adjustCSS('opacity', sprite, { from: '0.5' })

That is already how the opacity motion does it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants