- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 25 Jun 2013 11:01:41 -0700
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: www-style list <www-style@w3.org>
On Tue, Jun 25, 2013 at 10:24 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > On 6/25/13 9:47 AM, Tobias Ritzau wrote: >> Hi all, it seems as all major implementations of >> http://www.w3.org/TR/css3-transitions/ handle transitions from "display: >> none" the same way: there is no transition. That cause code that, as far >> as I can see, get complex for no reason. I can't trace this to the spec. >> Is it in there? > > > The relevant part of the spec is this: > > Since this specification does not define when computed values change, > > and in particular, UAs optimize out computing most style on display:none > things, so when the display changes other properties don't transition > because there is no computed value change for them, just an initial computed > value computation.... at least in UAs that do said optimizing out. > > >> What is the intended way to fade in an element that has display set to >> none? What I have done is to first set display to what ever that should >> be (and opacity to 0), and then using requestAnimationFrame() I have set >> opacity to 1. > > > This is not guaranteed to work, since nothing says that the display style > will get recomputed before you requestAnimationFrame callback. Certainly no > spec requires that. > > >> Is this guaranteed to work? > > > No. > > The only thing that is guaranteed to work in today's UAs is explicitly > asking for the computed value of the property you want to animate after you > make the display change. Everything that Boris has said is correct. ^_^ > For tomorrow's UAs, http://dev.w3.org/fxtf/web-animations/ will hopefully > define a better setup here. Yes, it will. ~TJ
Received on Tuesday, 25 June 2013 18:02:32 UTC