-
Notifications
You must be signed in to change notification settings - Fork 708
[web-animations-1] Specify how to compute property values #5255
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
Conversation
When it comes to the term "computed value", the spec is currently very confused. It appears to be making several references to "the" computed value (as in [1]), when in reality the intention is (I believe) to apply the *process* that calculates the computed value ([1]) to the value specified (locally) in the keyframe. This process is not described in a reusable way anywhere (I think), so I've added the algorithm "compute a property value" for this. I'm using the term "property value", since it's already extensively used in this spec. Possibly it would be more suited for css-cascade, but I'm proposing it for this spec until we need it somewhere else. In general I want to maintain a clear distinction between when we mean the actual computed value [1], and when we mean some value that has undergone the "compute a property value" process. Hence, I think we should avoid referring to a value that has undergone the "compute a property value" process as "a" computed value, as it's too easily confused with *the* computed value. I've included some text and an examples that hopefully clarify the expected interpolation behavior a little bit. It seemed somewhat natural to place this in the "Computing property values" section, since resolving dependencies is part of the process when computing values. [1] https://drafts.csswg.org/css-cascade/#computed
@birtles : Please review. I will try to tackle css-animations/getKeyframes as well, but since web-animations is responsible for the core animation behavior, we have to start here. (Also cc @kevers-google, @flackr) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me. I'm not sure if @tabatkins or @fantasai have any thoughts about if there is a better place for such a definition.
Also, as a very minor nit, we should probably aim to use more semantic line-breaking going forward (specifically, at least, starting new sentences on a new line).
console.log(getComputedStyle(elem).fontSize); // Should be 15px | ||
console.log(getComputedStyle(elem).width); // Should be 225px | ||
</pre> | ||
In this example, in order to <a>compute a property value</a> for |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: this link doesn't work for me. I think it needs to be [=compute a property value|computing a property value=]
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, thanks. Fixed.
(Although the broken link didn't appear on the source line you highlighted).
OK, I made that change in the most obvious places, at least. |
@birtles FYI, I don't have write access, so I can't merge this. (In case you're waiting for me). |
Sorry, I didn't realize you don't have write access! |
When it comes to the term "computed value", the spec is currently
very confused. It appears to be making several references to
"the" computed value (as in [1]), when in reality the intention is
(I believe) to apply the process that calculates the computed
value ([1]) to the value specified (locally) in the keyframe. This
process is not described in a reusable way anywhere (I think), so I've
added the algorithm "compute a property value" for this. I'm using
the term "property value", since it's already extensively used in this
spec. Possibly it would be more suited for css-cascade, but I'm
proposing it for this spec until we need it somewhere else.
In general I want to maintain a clear distinction between when we
mean the actual computed value [1], and when we mean some value that
has undergone the "compute a property value" process. Hence, I think
we should avoid referring to a value that has undergone the
"compute a property value" process as "a" computed value, as it's
too easily confused with the computed value.
I've included some text and an examples that hopefully clarify
the expected interpolation behavior a little bit. It seemed somewhat
natural to place this in the "Computing property values" section,
since resolving dependencies is part of the process when computing
values.
Fixes #5125.
[1] https://drafts.csswg.org/css-cascade/#computed