Web animations mishandle aliases with CSS wide keywords
Categories
(Core :: DOM: Animation, defect, P3)
Tracking
()
People
(Reporter: emilio, Assigned: emilio)
References
()
Details
Attachments
(1 file)
If you add -webkit-appearance
to the test here:
It fails. This bit me when trying to unprefix user-select.
Assignee | ||
Comment 1•6 years ago
|
||
I haven't looked much into this, but I believe it's unexpected that aliases work differently than the properties they alias to.
Let me know if you don't plan / don't have the cycles to dig into this and I'll do.
Assignee | ||
Comment 2•6 years ago
|
||
It's not particularly related to wide keywords:
animation = document.body.animate({ "transform": ["translate(0)", "translate(100px)" ] }, { duration: 1000 });
Works, while:
animation = document.body.animate({ "MozTransform": ["translate(0)", "translate(100px)" ] }, { duration: 1000 });
Doesn't
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Comment 4•6 years ago
|
||
This seems it's only used by web animations.
Updated•6 years ago
|
Comment 5•6 years ago
|
||
Emilio, I left some comments in the Phabricator review yesterday, not sure if you saw them. I'm currently just trying to make sure aliases for shorthands work correctly (e.g. -moz-columns? -webkit-flex? -webkit-mask?) but keep running out of disk space when I go to build.
Assignee | ||
Comment 6•6 years ago
|
||
I did see them, but was pretty busy today trying to get my transform patches landed so that Boris could rebase on top and such. I'll get back to this tomorrow or on monday.
Comment 7•6 years ago
|
||
Ok great, just making sure you weren't waiting on me to finish reviewing.
Comment 8•6 years ago
|
||
So I dug into this a bit because I wasn't sure how this was supposed to work.
In the past Web Animations had special handling for aliases along the following lines:
1. For user agents that support both a prefixed and an
unprefixed version of some CSS properties, remove all
prefixed properties from <var>animation properties</var>
where the corresponding unprefixed version is also
present in <var>animation properties</var>.
(i.e. the idea being to only read aliased properties if they weren't overlapped by anything else.)
This was dropped in: https://github.com/w3c/web-animations/commit/32413328b04d5ac4109b7424df00834de20a66ba#diff-8d4d847e6257b75f4bf8030496281de4L7468
The replacement text being added a few commits prior in: https://github.com/w3c/web-animations/commit/90e5a5319884892f51c26c293b5fc11c5c89094a#diff-8d4d847e6257b75f4bf8030496281de4R6922
I recall that at that time Google were pretty keen that Web Animations should not support prefixed properties at all. I persuaded them we had to have at least some support in order to represent CSS animations/transitions of properties for which there was no unprefixed version available.
That whole discussion happened before we started to specify these properties however.
So the current behavior is that we simply don't support aliased properties. That appears to be consistent across Chrome Canary, Safari TP, and Firefox at least for 'WebkitTransform': https://codepen.io/birtles/pen/byWmQx
But given that prefixed properties may be unprefixed by aliasing, I guess you're suggesting that we really should handle aliased properties (otherwise we would break any content using the prefixed version). That makes sense to me.
Given that, if you specify:
const anim = elem.animate({ MozTransform: 'translate(100px)' }, 1000);
console.log(anim.effect.getKeyframes());
What should you get?
{ MozTransform: 'translate(100px)' }
? i.e. alias resolution happens later{ transform: 'translate(100px)' }
? i.e. alias resolution happens on input{ MozTransform: 'translate(100px)', transform: 'translate(100px)' }
? both are returned?
Furthermore, what happens when you specify both, e.g.:
{ MozTransform: 'translate(100px)', transform: 'translate(200px)' }
Presumably transform
should win in that case (i.e. aliases lose to whatever they alias).
Of the options, I think we definitely don't want (3). It would be an authoring nightmare.
For similar reasons (2) is also pretty bad. e.g. the following code won't work:
const anim = elem.animate({ MozTransform: 'translate(100px)' }, 1000);
// Update target translation to 200px
anim.effect.setKeyframes({ ...anim.effect.getKeyframes()[0], MozTransform: 'translate(200px)' });
In that case we'd end up returning { transform: 'translate(100px)' }
, to which the code appends MozTransform
but that gets ignored when fed back in.
So it sounds like we need to change the spec to preserve aliases, i.e. (1).
That would mostly involve updating the section where we calculate computed keyframes to include rules for resolving aliases (like we already have to logical properties etc.)
If that makes sense to you let me know and I'll file a spec issue for this.
Assignee | ||
Comment 9•6 years ago
|
||
I think we should get 2. Right now alias resolution happens as soon as we parse the property basically.
Comment 10•6 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #9)
I think we should get 2. Right now alias resolution happens as soon as we parse the property basically.
With these patches we'll actually crash for this test case (due to assertions in PropertyIDLName
and PropertyIDLNameSortPosition
that that need to be updated).
However, with those fixed we'll get behavior 1. That's because we store the nsCSSPropertyID
in addition to the RawServoDeclarationBlock
.
These patches will still need extra work, however, to ensure we that when both MozTransform
and transform
are specified transform
wins. Test case: https://codepen.io/birtles/pen/xNLWvr
Let me know if you agree we want behavior (1) and go I'll go ahead and file the spec issue / PR.
Comment 11•6 years ago
|
||
(In reply to Brian Birtles (:birtles) from comment #10)
Let me know if you agree we want behavior (1) and go I'll go ahead and file the spec issue / PR.
Filed https://github.com/w3c/csswg-drafts/issues/3948 for this
Comment 12•6 years ago
|
||
The priority flag is not set for this bug.
:birtles, could you have a look please?
For more information, please visit auto_nag documentation.
Updated•6 years ago
|
Comment hidden (off-topic) |
Assignee | ||
Updated•2 years ago
|
Updated•2 years ago
|
Description
•