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

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

Received on Monday, 28 May 2012 16:54:29 UTC