I'm seeing a curious behavior when mixing CSS transitions with "display: none". Specifically, if you have an element set to "display: none", then set that element to be "display: block" and simultaneously change the element's class, the transition is skipped. This results in a fair bit of ugliness when, for example, fading in an overlay window. You end up having to instead push the content off the screen or change its size to zero in combination with "overlay: hidden", neither of which is nearly as clean as preventing interaction by actually making the element be non-rendered. I see nothing in the spec that suggests that this behavior is correct, so I'm assuming it is a bug. I realize the underlying issue—that at the time the transition would begin, the element's layout probably hasn't been calculated yet—but it would make a lot more sense if WebKit recognized that the element was in such a transitional state and rescheduled application of that transition after the next draw loop, rather than skipping the transition and applying the final style to the initial layout as it appears to do now. Minimal example attached. When you click the button, content should shift around immediately (when the "display: block" gets applied), but then the actual content of the div should fade in.
It doesn't seem like the test case was attached. If you believe there is still a problem, could you please attach a test case?