RE: [css3-transitions] display properties missing; delay property unclear

It would be really nice if 'display' could be part of a transition/animation.
'display' allows you to do more interesting things because of the way sub-animations are handled.

Ie let's say you want to move a box from left to right over a duration of 10s but with a delay of 3s and you want to repeat this.
So: invisible for 3s and then animate from left to right for 10s.
This box will also have a subanimation that rotates it over 5s. (I know you could collapse the 2 states but this is a simplified example)

Currently there is no way to do this with css without resorting to JavaScript.
The reason is that you need to set visibility to false/true to hide/display the box, but this does not stop the rotation from starting at time 0.
By the time the box is visible, it would already be partly rotated.

By having 'display' as part of the keyframes, the subanimation wouldn't start until the box had the property 'display: block'

Rik

From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of Belov, Charles
Sent: Thursday, January 20, 2011 2:41 PM
To: Belov, Charles; www-style list
Subject: RE: [css3-transitions] display properties missing; delay property unclear


I note from http://www.w3.org/TR/css3-transitions/ that visibility can be transitioned (despite only having two states, visible and hidden) but display, which also has only two states, cannot.  This is a potential issue as I am seeing reports that Webkit browsers make hidden links clickable.   Furthermore, I am concerned there may be an issue with a hidden layer blocking activation of a link on a visible but further-back layer.  (Unless, of course, CSS3

The use case I am concerned with is a time-delay cascading menu.  Currently, this can only be accomplished with JavaScript.  I would like to see CSS Transitions support it, but this requires that display be animated.

The idea of a time-delay cascading menu is to

1. avoid accidental activation, as when one moves ones cursor from above a horizontal cascading menu to below that menu without intent to interact with it.  Under current CSS cascading menus, the menu gets activated against the end-user's intent, sometimes even blocking the screen location where the end-user was intending to go to.  Also,

2. avoid accidental deactivation, as when a person navigating their cursor through the activated menu inadvertently cursors off the menu momentarily.

Using the guidelines provided by Jacob Nielsen under "Speed" on http://www.useit.com/alertbox/mega-dropdown-menus.html, I would expect to be able to code something like:

div#cascadingmenu ul li {
transition-property: display;
transition-duration: 100ms;
transition-delay: 500ms;
display: none;
}

div#cascadingmenu:hover ul li {
display: block;
}

(Except that "display" is currently not one of the transitionable properties.)

I'm also concerned with some wording under http://www.w3.org/TR/css3-transitions/#starting:

Once the transition of a property has started, it must continue running based on the original timing function, duration, and delay, even if the 'transition-timing-function', 'transition-duration', or 'transition-delay' property changes before the transition is complete. However, if the 'transition-property' property changes such that the transition would not have started, the transition must stop (and the property must immediately change to its final value).

versus http://www.w3.org/TR/css3-transitions/#the-transition-delay-property-

Otherwise, the value specifies an offset from the moment the property is changed, and the transition will delay execution by that offset.

That is, are "execution" and "running" synonymous?  The question is whether, if the end-user's cursor passes over an element, activating "hover" (setting display to "block") and then exits (because there was not intent to interact) within the 500ms before the transition begins, setting display back to "none", would cause the end value of display to be "none" or "block".

Hope this helps,
Charles Belov
SFMTA Webmaster

Received on Friday, 21 January 2011 18:22:31 UTC