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

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
http://stackoverflow.com/questions/2828118/hidden-links-are-still-clicka
ble-on-the-android-browser

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



Hope this helps,
Charles Belov
SFMTA Webmaster

Received on Friday, 21 January 2011 18:58:58 UTC