662351 - Allow keyframe animations and transitions to work on the ::-moz-progress-bar pseudo element

Status: NEW

(Core :: CSS Parsing and Computation, enhancement)

Description

[Jason Ng]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a2) Gecko/20110606 Firefox/6.0a2
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a2) Gecko/20110606 Firefox/6.0a2

I know it's non-standard in the first place but with being able to style the progress bar of a progress element using ::-moz-progress-bar but I've determined that css transitions and animations won't work on it.

In an attempt to simulate a progress bar that's sort of like the windows 7 default system one, it would help if you could at least animate something like the background position.

Reproducible: Always

Comment 1

[Mounir Lamouri (:mounir)]

It is possible to animate progress but not the anonymous child. Are animations disabled for anonymous child on purpose or is that a bug?

Comment 3

[Boris Zbarsky [:bzbarsky]]

Animations and transitions are tied to elements.

::before and ::after pseudo-elements are explicitly special-cased to also work.

You could try adding such special-casing for ::-moz-progress-bar and seeing what happens....

David, do you recall why we didn't just allow transitions on all pseudo-elements?  I guess there's the issue of figuring out which Element to actually hang the transitions off of, since this differs for different pseudo-elements...

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I suppose we could store pseudo-element transition/animation data in a hash table in the element properties.

The motivation for storing the data on elements was preserving it across reframes; the pseudo-element anonymous content is not preserved across reframes (as far as I know, anyway), so it's all stored on the real element.

Comment 5

[Boris Zbarsky [:bzbarsky]]

We could store it as we do now; just have a list of atoms that correspond to all the pseudo-element IDs.

> The motivation for storing the data on elements was preserving it across
> reframes

That's probably worth documenting in the code.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #5)
> We could store it as we do now; just have a list of atoms that correspond to
> all the pseudo-element IDs.

That leads to a lot of property lookup when removing nodes from the tree, though, to check for and destroy each property, and it means adding new code for each new pseudo-element (possibly via preprocessing hacks, but it's still new code).

Comment 7

[Boris Zbarsky [:bzbarsky]]

Hmm.  That first is a good point.  The second would be automatic if we used nsCSSPseudoElementList right, as you note, but the first is something that would best to avoid.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Attachment: Make sure to skip animation rules as well as transition rules when we're reparenting a style context when not processing an animation restyle.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Attachment: Make sure to skip animation rules as well as transition rules when we're reparenting a style context when not processing an animation restyle.