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

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

From: Belov, Charles <Charles.Belov@sfmta.com>
Date: Fri, 21 Jan 2011 10:52:19 -0800
Message-ID: <E17F75B6E86AE842A57B4534F82D03769C35BF@MTAMAIL.muni.sfgov.org>
To: "Simon Fraser" <smfr@me.com>
Cc: "www-style list" <www-style@w3.org>
Simon Fraser [mailto:smfr@me.com] wrote on Thursday, January 20, 2011
11:14 PM:
> 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.

Right, but in a transition there would only be two states, e.g. "none"
and "block".  You couldn't transition from "none" to "block" to "inline"
in a single transition.

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

I had not personally tested this.  I only know of these complaints from
a search on the terms 

visibility hidden clickable

One post provides a test case
http://icant.co.uk/sandbox/hiddenNotGone.html and I see it is no longer
an issue in Safari (if it was an issue, as claimed at
http://archivist.incutio.com/viewlist/css-discuss/72025 in 2006).   But
someone is claiming it is still an issue on Android as of May 2010

My (side) concern is that it be somewhere in the CSS3 spec that if
something is not visible (visibility:hidden) that it also not be
clickable.  I'm not sure where to find that in the specs.  

In any case I apologize for distracting side issue.

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

Again, it is a side issue.  The relevant point is that I want to be able
to transition display similar to what is being allowed for visibility,
that is between two different values.
> > 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.

But if it is in fact usable to do those things, why not allow it?
> > 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.

Then why is it possible on visibility?  For visibility it states:

visibility: interpolated via a discrete step. The interpolation happens
in real number space between 0 and 1, where 1 is "visible" and all other
values are "hidden". 

so why not:

display: interpolated via a discrete step. The interpolation happens in
real number space between 0 and 1, where 1 is a single rendered state
and all other values are "none". 

to at least allow transition between "none" and another state?

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

Good, that's what I would want.  However, I believe the wording could
make this clearer in the case of use of a positive value for

Hope this helps,
Charles Belov
SFMTA Webmaster
Received on Friday, 21 January 2011 18:58:58 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:42 UTC