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

[web-animations-2] Update ComputedEffectTiming #6712

Merged
merged 4 commits into from
Oct 14, 2021
Merged

Conversation

kevers-google
Copy link
Contributor

[web-animations-2] Update ComputedEffectTiming

This PR fixes descriptions in ComputedEffectTiming to remove ambiguity over the return value types. Specifically, effects linked to animations with timelines that have an unresolved duration should return times expressed as doubles in milliseconds and not as CSSNumericValues. Only progress based animations should return their time values expressed as CSS.percent.

The progress attribute was previously changed to be of type CSSNumberish but without a description change. This property is a fraction and not a time. Thus, it should not have been changed. The change is reverted in this PR.

A few formatting fixers were applied to clearly show the type for each attribute in the "members" section.

};
</pre>

<div class='members'>

: <dfn dict-member for=ComputedEffectTiming>startTime</dfn>
:: The <a lt='animation effect start time'>start time</a> of this
<a>animation effect</a> in milliseconds or as a percentage of the
<a>animation effect</a> expressed as a double in milliseconds
if [=timeline duration=] is unresolved or as a percentage of
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We seem to be using an unresolved timeline duration as an alternative to associated with a progress based timeline, however the latter is a better reason for the startTime to be expressed as a percentage - whereas if we had a finite time-based timeline I could see the time being expressed either way and most likely using a double for compatibility.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Switched to being explicit about using % only with a progress based timeline. Switched ordering to avoid negative condition or otherwise, which feels awkward.

@flackr flackr merged commit 0a63270 into w3c:main Oct 14, 2021
saschanaz added a commit to saschanaz/webref that referenced this pull request Oct 23, 2021
It's [removed from level 2 spec](w3c/csswg-drafts#6712) and thus should be restored.
tidoust pushed a commit to w3c/webref that referenced this pull request Oct 27, 2021
It's [removed from level 2 spec](w3c/csswg-drafts#6712) and thus should be restored.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants