Firefox seems to work fine

The difference is that the first animation is composited and the second is not (due to the %). Adding 'background: red;' to the first animation will also cause it to block (as it will be forced onto the main thread).

Testing other browsers (using http://output.jsbin.com/nekerop + browserstack):

Firefox: Doesn't block the animation.
Edge: Doesn't block the animation.
Safari: Doesn't block the animation.

So looks like this is a Chrome-only issue, we should address it. The implications may be rather large, however, depending on why we are't ticking animations (e.g. is the whole of blink blocked?)

Eugh, the above information is tainted by split-thread animations on Edge and Safari, and may be tainted if Firefox composites color animations. Please ignore #2, I'm going to redo the test.

Ok, so it turns out that all the browsers are consistent apart from Firefox. http://output.jsbin.com/nekerop is an updated test that now animates height (which is definitely absolutely main thread)

Chrome: main pauses, split pauses (since we don't support split animations), composited keeps going
Firefox: keeps running all three including main-thread!
Edge: main pauses, split pauses color but keeps transform going, compositor keeps going
Safari: main pauses, split pauses color but keeps transform going, compositor keeps going

In terms of Chrome, we view this as a WontFix. The spec allows the user-agent to pause main-thread operators at will for alert (https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#dom-alert), and our compositor behavior is aligned with all three other browsers. Firefox is really the odd-one-out as they continue to animate main.

We are currently discussing implementing split-thread animations in Chrome, given all other browsers appear to support it.

Thank you for the bug report though, I learnt a lot today about split-animation support and composited/main animations!