W3C home > Mailing lists > Public > www-style@w3.org > January 2011

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

From: Simon Fraser <smfr@me.com>
Date: Thu, 20 Jan 2011 23:13:51 -0800
Cc: www-style list <www-style@w3.org>
Message-id: <6CDF22F1-FFDE-48C4-A6CC-BF26F59F26D4@me.com>
To: "Belov, Charles" <Charles.Belov@sfmta.com>
On Jan 20, 2011, at 2:41 PM, Belov, Charles wrote:

> 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.

display has 'none', 'block', 'inline', 'inline-block', 'table-cell' etc etc, so more than two states.

>  This is a potential issue as I am seeing reports that Webkit browsers make hidden links clickable.

Can you expand on this, with an example or by the filing of a bug at bugs.webkit.org?

> 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

I don't understand this paragraph.

> 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.

It is not the goal of CSS transitions to deal with complex user-interactive content that requires special event handling to avoid usability issues. So for cases like this, you may be able to use transitions for some of the visual effects, but it's likely that you may still have to run some JS to tune the user interaction.

> 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;
> }

With CSS transitions, every intermediate state has to be representable through CSS, and, indeed, getComputedStyle() will return you the appropriate style if you call it while the transition is running.

What you're describing here is magic where the UA concocts some kind of presentation of an element that is half way between being not displayed at all, and being display:block. There's just no way to specify or implement this.

> (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".

Transitions never affect the final value of a property. When the transition is done, the target properties all have their final values as described by the normal style rules.

If a transition is in its delay phase but is interrupted (in your case by unhover), then the property is never animated.

Received on Friday, 21 January 2011 07:14:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:55 UTC