1187571 - event to detect when css are applied after dom modification

Status: UNCONFIRMED

(Core :: CSS Parsing and Computation, defect)

Description

[vito.detullio]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:39.0) Gecko/20100101 Firefox/39.0
Build ID: 20150703143539

Steps to reproduce:

The scenario is described on http://stackoverflow.com/questions/12088819/css-transitions-on-new-elements:

* I have a js that inject a new element on the dom
* according to css rules, this element has opacity:0 and a transition set.
* in js, there is a rule that, at the triggering of an event ("the new element is correctly positioned in the dom, the css rules are applied, etc"), add a new class to the new element, making it changing the opacity to 1.

In the scenario, there were these candidates for the "event"
* worst: a setTimeout to "wait" 5-6 millis (it's just an heuristic)
* hackish: force a layout recalculation (es: accessing the clientHeight attribute)
* "best"?: using requestAnimationFrame.

now, using firefox 39 with requestAnimationFrame I still get bugged and see no transition.
I don't know if this is the "semantically correct" one: if there is a better (explicit) way to know, I will happily change my code, but if requestAnimationFrame was supposed to work, this is the bug :) 


Actual results:

the element is directly with opacity 1, no transition


Expected results:

a "fadein" animation of the element

Comment 1

[Nickolay_Ponomarev]

See http://stackoverflow.com/a/31862081/1026 and bug 649247. There was an idea to provide an API to start the transition from script (bug 774655), but I agree that an official response on whether:

- requestAnimationFrame callback is supposed to only run after the restyle
- another event can be added for this
- web developers should just stick with getComputedStyle(document.documentElement, "").color? (Is that incantation supposed to work in every browser following the specs?)

would be very helpful.

Comment 2

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

(In reply to Nickolay_Ponomarev from comment #1)
> See http://stackoverflow.com/a/31862081/1026 and bug 649247. There was an
> idea to provide an API to start the transition from script (bug 774655), but

Yes, we should either do this or agree that there's a way to do it via Web Animations.

> I agree that an official response on whether:
> 
> - requestAnimationFrame callback is supposed to only run after the restyle

I think we generally want requestAnimationFrame callbacks to be as early in the process as possible so that authors can *write* their changes that cause additional work without causing double work.  Maybe others disagree or that's not the current practice, though; I haven't been following that space closely.

> - another event can be added for this

I'd rather not add an event for this.  I suspect it seems likely to encourage patterns that are slow (i.e., forcing double work to happen), although maybe I'm misunderstanding what the event would be.

> - web developers should just stick with
> getComputedStyle(document.documentElement, "").color? (Is that incantation
> supposed to work in every browser following the specs?)

That's bad for performance, but it should work cross-browser.  It just flushes style, which means doing more restyle work than needed.

Comment 3

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

To clarify my comment on requestAnimationFrame -- I think we should optimize requestAnimationFrame to be a good place to make changes rather than optimizing for reading state there.