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

I'm not suggesting that other properties be affected by animating
`display`, per se, just that the appearance be animated in a similar manner
to that of the `height` or `width` property transition (nowhere did I
mention `opacity`, I guess you got that from jQuery). What I'm suggesting
is a simple transition from one value to another, either the rendered box's
physical height or width. It isn't any more complex than animating the
`width` or `height` properties themselves; as far as I can tell, the only
complexities would occur when either the from or to value isn't `none` --
for which, I'm suggesting we do not animate if there are technical problems
with doing so.

Basically, I'm pretty much trying to say that at least some form of
animation on the `display` property would be a great asset to web
developers and, after thinking a great deal about it, the only type of
animation that makes sense to me is incremental adjustments to the
rendering box's height or width. If that seems odd to you, perhaps you have
an idea of how `display` could be animated in a more appropriate manner?
Like I said before, some box types cannot be animated as simply as most web
developers would like and animating the `display` property would fix this.

On Mon, May 28, 2012 at 5:53 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> On Mon, May 28, 2012 at 9:04 AM, Andy Earnshaw <andyearnshaw@gmail.com>
> wrote:
> > Taking any technical limitations or complications into account, I
> believe it
> > would be possible to animate the display property in certain
> circumstances,
> > at least when animating from `none` to any other value or from any value
> to
> > `none`.  Arguably, one of the most desired effects is to have an element
> > hidden, not affecting the layout of the page and transition it to visible
> > via a sliding animation (e.g. a "read more" link expanding a block). This
> > can be achieved with current transitions for some box types by
> transitioning
> > the `height` or `width` properties whilst `overflow` is set to
> > `hidden`. However, there are some box types that are very difficult to
> > animate in this manner, such as `inline` boxes or
> `table-row`/`table-cell`
> > boxes that do not support the `overflow` property to the same extent that
> > `block` or `inline-block` boxes do.
> >
> > While I can understand that transitioning from inline to block may be
> > somewhat complicated, transitioning from none to any value or vice versa
> > should be as simple as how JavaScript libraries like jQuery emulate the
> > task. For instance, transitioning from `none` to `block`, `table`,
> > `table-row` and similar box types would involve initially rendering the
> box
> > at the final computed width value, followed by transitioning the box's
> > height from 0 to the final computed value. Transitioning from `none` to
> > `inline`, `inline-block` and similar box types would involve initially
> > rendering the box at the final computed height value, followed by
> > transitioning the box's width from 0 to the final computed
> > value. Transitioning to `none` from those values would just work in
> reverse.
> >
> > If anybody would like a viable use-case, consider the problem I'm
> currently
> > facing. I have a table containing data, with some rows considerably
> relevant
> > to the page visitor and others less relevant. Those less relevant rows
> are
> > hidden from the visitor by default, until they click the table, in which
> the
> > hidden rows are then made visible. The almost-working solution I have at
> the
> > moment -- animating the font-size and border-width of those rows -- is less
> > than elegant, with the final result varying between browsers. What
> should be
> > a very simple task turns out to be over-complicated and frustrating,
> which
> > is what spurred me to propose this change to the specification.
> >
> > Hopefully, I'm not missing some important technical limitation that makes
> > this more difficult than my brain thinks it is.
>
> 'display' isn't animatable because it only accepts keyword values, and
> keywords aren't animatable yet.  We'll allow animating keywords in
> some manner in the future.
>
> The particular type of animation that you argue for (a complex
> fade/slide) is a little strange, too.  All of the animations so far
> are simple interpolations from one value to another.  Changing
> multiple other properties (opacity, positioning) in order to animate
> 'display' is much more complex.  As well, jQuery for example has three
> different show/hide pairs built into the core - one that animates
> opacity, width, and height, one that just does opacity, and one that
> does a horizontal or vertical slide.  All of these are reasonable
> answers, and so baking any one of them into the spec as the "correct"
> way to animate display seems odd.
>
> ~TJ
>