|Ability to CSS animate <progress> pseudo elements regressed|
|Reported by david0ev...@gmail.com, May 8 2015||Back to list|
Chrome Version : 42.0.2311.135 URLs (if applicable) : http://codepen.io/phosphoer/pen/VLemML Other browsers tested: Add OK or FAIL after other browsers where you have tested this issue: Safari 8: OK What steps will reproduce the problem? 1. Go to http://codepen.io/phosphoer/pen/VLemML 2. See the <progress> is a green bar 3. Observe there is no red bar animating back and forth What is the expected result? A red bar is visible animating back and forth within the <progress> element. What happens instead? No red bar is displayed. Please provide any additional information below. Attach a screenshot if possible. WinJS applies a custom CSS animation to -webkit-progress-value for an indeterminate progress bar. In recent versions of Chrome this functionality has been regressed and the animation isn't displayed.
May 18 2015,
May 18 2015,
You are probably looking for a change made after 309810 (known good), but no later than 309811 (first known bad). NOTE: There is a Blink roll in the range, you might also want to do a Blink bisect. CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/c79721698e112d34ca896d84f756d75c0f409c85..51c3770a418580ef694b756ef66b9d185711c640 Blink Roll -> https://chromium.googlesource.com/chromium/blink/+log/b39f4fe..7cd71f8 Just one change: https://chromium.googlesource.com/chromium/blink/+/7cd71f8c2910cfc8aaf70931a3a266fc3f0ec148 "CSSAnimations should not use ScopedStyleResolver" -> kochi
May 22 2015,
Tentative fix uploaded: https://codereview.chromium.org/1149383003/ I am not sure this is an expected behavior. Help from CSS animation spec experts needed. If @keyframes rule is strictly scoped, progress::-webkit-progress-value and @keyframes progress should not match, as the progress::-webkit-progress-value is not in the same treescope. But the fact that the progress is actually a user agent shadow is an implementation detail of Blink, so to match Safari's behavior, I think the fix is a reasonable compromise.
May 25 2015,
Closing this as WontFix. Reason: @keyframes rule name is scoped, so the name specified is only available in the same treescope (i.e. in the same document or shadow root). progress::-webkit-progress-value pierces document-UA shadow root boundary and styles the element, but animation name defined in the document treescope isn't available in UA shadow root, thus the animation doesn't apply. This breaks compatibility with Safari/WebKit, but in general, -webkit- is only available for WebKit/Blink-based browsers and not interoperable among all browsers, and thus the usage is discouraged. A workaround could be to make your own widget and animate it, which should work all (if CSS animation is implemented) browsers.
|► Sign in to add a comment|