Test case: https://jsfiddle.net/g7ubn9te/

From my monologue on #webanimations:

15:33 <birtles> oh, I think I found a fairly decent bug in the spec
15:33 <birtles> basically, this test case: https://jsfiddle.net/g7ubn9te/
15:33 <birtles> in Firefox it fills
15:34 <birtles> (regardless of the fill mode)
15:34 <birtles> in Chrome it doesn't
15:34 <birtles> (regardless of the fill mode)
15:34 <birtles> Firefox is doing the correct thing by the spec but it's not particularly intuitive
15:34 <birtles> basically finishing behavior and phases don't line up
15:35 <birtles> Finishing behavior: once you get to zero stop
15:35 <birtles> Phases (on which fill modes are based): the boundary between the before phase and active phase can be negative
15:36 <birtles> so basically, the spec says that when you play backwards keeping going until you get to zero and then stop, even if that means you remain forever stuck in the active phase
15:51 <birtles> I'm actually not sure what the preferred result is
15:51 <birtles> on the one hand I'm tempted to say we should play backwards to the beginning of the delay, even if that time happens to be sub-zero
15:51 <birtles> but I think we deliberately wanted the negative delay to give you that kind of clipping effect
15:52 <birtles> if that's the case then we probably should still not fill indefinitely
15:54 <birtles> but achieving that would probably mean you could never seek into the negative range, i.e. it's completely clipped, not just shifted on the timeline
15:56 <birtles> so I think we want to play backwards to the beginning of the delay, even if that happens to be sub-zero