W3C home > Mailing lists > Public > www-style@w3.org > May 2012

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

From: Rik Cabanier <cabanier@gmail.com>
Date: Mon, 28 May 2012 20:50:36 +0200
Message-ID: <CAGN7qDBpX0MnVeBOCXH+SySDSigKnmOe3aoz3p49uo08ruwQwg@mail.gmail.com>
To: Andy Earnshaw <andyearnshaw@gmail.com>
Cc: www-style@w3.org
I agree.
We've had multiple cases where we wanted to have the display property to be

This has been brought up multiple times and was always mentioned as
something that we would get in the near future (even by Tab)...

On Mon, May 28, 2012 at 6:04 PM, 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.
Received on Monday, 28 May 2012 18:51:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:17 UTC