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

On 21/01/2011 6:13 PM, Simon Fraser wrote:

Replies to both Simon and Charles.

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


Does this not affect accessibility?


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


He's referring to the two states for where the initial state is a 
block-level box and the other state that hide the box completely is 
display none.


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


Menus like this are positioned or at least have a stacking context. 
Since they are painted above content but are hidden (due to it's 
visibility), any content that is under or below this part of a drop down 
(sub menu) can not be activated (text can not be selected nor can link 
be hovered).


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


Hold on. Sometimes JS maybe be disabled. Anyway a delay is possible with 
CSS transitions which allows a user to inadvertently cursors off the a 
menu momentarily. The problem Charles is dealing with is nested list 
(typical hidden in their initial state) which is levering a user event 
on a parent element.

Below is a demo with transition with duration for hover in (has focus) 
events and hover out (non focus) events and delay for hover out (non 
focus) events. All transitions occur on the anchor links.

<http://css-class.com/test/css/3/expanding-tabs-with-transition.htm>


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


Going to the first example cited by Jacob Nielsen (the food network), I 
note these accessibility issues.

1. The first issue is that tabbing does not show what links are in 
focus. If the hiding and showing of the sub menus done via display none 
and display block this also block a keyboard user from accessing the sub 
menu links. This breaks keyboard accessibility.

2. The Second issue is that font size is frozen with absolute units so 
one must change the minimum font size setting in FF and Opera or the 
universal access font size setting in Safari. With IE this is worst.


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


Are you sure it's not implemented already in some fashion.


<http://css-class.com/test/css/3/transition-with-min-width-and-max-width.htm>


-- 
Alan http://css-class.com/

Armies Cannot Stop An Idea Whose Time Has Come. - Victor Hugo

Received on Saturday, 22 January 2011 10:37:19 UTC