According to Bug 1244590 comment 53 and Bug 1244590 comment 54, we may need to get used values, instead of computed values, for eUnit_Calc while computing distances for paced spacing [1]. [1] https://dxr.mozilla.org/mozilla-central/rev/b0096c5c727749ad3e79cbdf20d2e96bd179c213/layout/style/StyleAnimationValue.cpp#587-594

In order to computed cumulative distances for paced spacing correctly, we need to get used values, instead of computed values, if the common unit is eUnitCalc. MozReview-Commit-ID: J8d442aJP6O

MozReview-Commit-ID: Jcx4sQxSIdy

Is that logic really sufficient to determine what percentages mean for all properties that have computed calc in the style structs? What guarantees that people adding new CSS properties don't get this wrong? (I'd really like to avoid duplicating that sort of information in more places.)

(In reply to David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) from comment #3) > Is that logic really sufficient to determine what percentages mean for all > properties that have computed calc in the style structs? What guarantees > that people adding new CSS properties don't get this wrong? > > (I'd really like to avoid duplicating that sort of information in more > places.) Thanks for your comment, David. Actually, I'm not sure how to fix this problem in a proper, and could you please give me some advises for this? So I can have more ideas about fixing the problem mentioned in Bug 1244590 comment 53. I think this patch is just a workaround and we need a more suitable way to calculate the cumulative distances if the common units of some pairs of Keyframes are eUnit_Calc and the reset are eUnit_Coord. Thanks.

Yeah, I'm a little bit unsure about this feature. I was reworking this part of the spec recently and it seems a little odd to require used values in this calculation--that is, it seems a little odd to have to flush layout to determine keyframe offsets. Perhaps we can just leave this behavior out of the spec for the time being and operate on computed values. I think if we later decide it's necessary to add this behavior then it's unlikely to break content. (Authors mixing percentage and length values will likely notice that they don't get the desired effect and rework their content to use either percentages of lengths.)

As discussed with dbaron yesterday, we should just use computed values for this. This, of course, needs to be specced still.

I've updated the spec to longer require using used values: https://github.com/w3c/web-animations/commit/87ad252447423f9ecbe8e787e1c7552764642734

(In reply to Brian Birtles (:birtles) from comment #7) > I've updated the spec to longer require using used values: > > https://github.com/w3c/web-animations/commit/ > 87ad252447423f9ecbe8e787e1c7552764642734 Thanks for your update, Brian. And I think we can also add some tests for this [1] in Bug 1274944. [1] http://searchfox.org/mozilla-central/rev/740bb4ed16d070cf5d466231b30e80b9204aec54/testing/web-platform/tests/web-animations/animation-model/keyframe-effects/spacing-keyframes.html#325