New issue
Advanced search Search tips
Starred by 4 users
Status: WontFix
Owner:
Closed: May 2015
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug-Regression



Sign in to add a comment
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. 
 
Comment 1 by tkent@chromium.org, May 18 2015
Labels: Needs-Bisect Cr-Blink-Animation Cr-Blink-HTML Cr-Blink-HTML-Progress
Labels: -Type-Bug -Needs-Bisect Type-Bug-Regression Cr-Blink-CSS
Owner: kochi@chromium.org
Status: Assigned
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
Comment 3 by kochi@chromium.org, May 22 2015
Cc: dstockwell@chromium.org
Status: Started
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.
Comment 4 by kochi@chromium.org, May 25 2015
Status: WontFix
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