Re: [css3-transitions] Why isn't the display property animatable?

> On Tue, May 29, 2012 at 2:28 AM, Lea Verou <leaverou@gmail.com> wrote:
> 
> > This will be solved easily once every value becomes animatable 
> > (through a discrete step, if nothing more elaborate is possible). Tab 
> > said this has been discussed in the WG and it will eventually be 
> > done, probably through the addition of a new timing function, to 
> > avoid breaking existing websites (which is unfortunate as it lacks 
> > consistency and elegance, but understandable). Then you could use 
> > `display` in keyframes to control when the change happens and 
> > simultaneously animate opacity, width, height or anything else. For 
> > example, a fade out:
> >
> > @keyframes fade {
> >    from { display: block; opacity: 1; }
> >    99% { display: block; opacity: 0; }
> >    to { display: none }
> > }
> 
> 
> The only issue I have with that idea is that you still have the problem 
> of animating elements that aren't block elements in a smooth manner. For
> instance, animating `opacity` with `display` will cause surrounding
> elements to snap to a new position before the animation starts (or after
> it finishes if you're fading out). That's why it makes more sense, or at
> least I think it does, to slide out the rendering box because it's the 
> most natural way for an element to gradually display when affecting 
> flow.
> 
> For the purposes of hunting a Gecko rendering bug, I put together a 
> simple demonstration (http://jsfiddle.net/NprYn/) that animates table 
> rows. The aforementioned hoops I had to jump through were; setting a 
> border on the TABLE element, setting top/left borders on each 
> individual TD element and then animating `border-width` and `font-size` 
> for those TD elements to hide them completely. I really don't think any 
> of us would agree that a theoretically simple animation should be this 
> tricky (and buggy -- I'm looking at you, Gecko). Naturally, we can't go 
> back in time or make any compatibility breaking changes to box 
> rendering and the only other option I could think of is having `render-
> height` and `render-width` properties, which could solve the problem 
> for this and other box types.

While there's a clear and common use case for this kind of animation I don't believe that "display" should be abused for this. For a light switch you also just have on and off. The same applies to "display". Either it is "none", or it is "block", or "inline", or something else. It can't be something in between. And letting the animation of "display" influence other properties like "width" and "height" doesn't seem very nice to me.

Sebastian
-- 
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!                                  
Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a

Received on Tuesday, 29 May 2012 11:54:48 UTC