Non normative edits.

[estelle]

Three separate commits. If you prefer separate pull requests instead, please let me know.

1. negative delays impact animation duration
2. animation iteration can be 0 or greater.
3. paragraph sentences reordered for clarity.

[tabatkins]

Thanks for the commits, but you're editting the generated file, not the source file, so it'll get wiped out the moment the repository auto-regens the spec. ^_^

[dbaron]

A few comments on the actual edits:

1. I'm not sure what this sentence even means. But it's not clear to me why it would be affected by only negative delays and not positive ones. I think I might prefer removing the sentence, but should probably look more closely.

2. looks great

3. I think the sentences are really mostly unrelated. It might be better if they were 2 separate paragraphs. But I think there's also something missing here about how properties in one keyframe rule override another. That should have been written for the edit under "2013-02-20 minutes", but I don't think it was.

[estelle]

When I resubmitted the PR to the correct file I left off 1) as the sentence seemed to read that the timing of the animationend had to do with those properties, but on re-read of your comment and the text, it doesn’t actually seem to mean anything.
In terms of 3) what does that paragraph mean? When we animate multiple properties, in the end it's as if a separate animation was created for each property. That is why switching the animation-timing-function during a keyframe only impacts the property/value pairs within that keyframe.

-Estelle

Estelle Weyl
http://www.standardista.com

On Jul 25, 2015, at 11:17 AM, David Baron [email protected] wrote:

A few comments on the actual edits:

1. I'm not sure what this sentence even means. But it's not clear to me why it would be affected by only negative delays and not positive ones. I think I might prefer removing the sentence, but should probably look more closely.

2. looks great

3. I think the sentences are really mostly unrelated. It might be better if they were 2 separate paragraphs. But I think there's also something missing here about how properties in one keyframe rule override another. That should have been written for the edit under "2013-02-20 minutes", but I don't think it was.

—
Reply to this email directly or view it on GitHub #41 (comment).

[dbaron]

Actually, rereading (3) again, I think the order it's in does make sense, although it could certainly be clearer.

What it's trying to say is that if you have:
0% { top: 0; left: 0 }
50% { top: 50px }
100% { top: 100px; left: 100px }
and you're using an 'ease-in' timing function, top animates over two separate uses of that ease-in timing function, wherease left animates only over a single easing function. There's no attempt to infer some value for left at 50% and act as though there are two pieces to the left animation. (And likewise, if the timing functions were specified in the keyframes, they'd only matter for a property if that property is in a keyframe at that percentage.)

[estelle]

Where it reads “property proceeds as if that keyframe did not exist”, makes it sound like the full keyframe gets obliterated, even the valid property/value pairs. The next paragraph clarifies that, so inverting the paragraphs makes the 1st sentence make more sense.
-Estelle

On Jul 25, 2015, at 11:44 AM, David Baron [email protected] wrote:

Actually, rereading (3) again, I think the order it's in does make sense, although it could certainly be clearer.

What it's trying to say is that if you have:
0% { top: 0; left: 0 }
50% { top: 50px }
100% { top: 100px; left: 100px }
and you're using an 'ease-in' timing function, top animates over two separate uses of that ease-in timing function, wherease left animates only over a single easing function. There's no attempt to infer some value for left at 50% and act as though there are two pieces to the left animation. (And likewise, if the timing functions were specified in the keyframes, they'd only matter for a property if that property is in a keyframe at that percentage.)

—
Reply to this email directly or view it on GitHub #41 (comment).

[birtles]

Re (1), I agree with dbaron's comment and will remove that sentence altogether.

[birtles]

Re (3), I agree that the sentence, as it stands, makes more sense than inverting the order. However, I hope we can make this more clear when we address issue #71.