ElkArte Community Modern, Free, Powerful
Community building forum software

Menus are slick (and I love admin/mod menus!), color scheme so pleasant to the eye, things are in the right place and repond so nicely!

Dis is a major bug. It keeps people browsing around on teh forums and do things for the sake of it.

(Ask Spuds, he already hates me messing around.)

I like the smoother animation. However, adding boxshadow tend to make it less responsive..this I have noticed using Mootools too, so I guess its too much for the average PC to render. An alternative would be to either use a sprite or not use boxshadow at all. Shame to ruin the nice animation it is now.

But it is running box-shadow. So if it's smooth now, why should box-shadow be a problem?

No, theres a noticeable lag there. If it was just an image, the animation would not be hampered by anything.AFAIK boxhsadow requires computing power, not much, but the "frames" need to be rendered too.So a normal instant menu with boxshadow looks fine, while animated does not. Its the same if you use css transtions too, though not so much as with javascript.

Its a small detail, but thats my experience with it anyway. i test it on an average machine - 512mb gfx/2.2Mhz duocore - and not the typical gaming/high spec with 2gb gfx and i7 processor. If you do, it might look better..but IMHO it will be a false positive then.

Ok, well your previous post seemed to be saying that you liked the way the animation was now.

You are aware that there is supposed to be a slight lag before the menus open? If you're not talking about that, but about the animation itself once it's underway, then maybe it should be looked into.

I have a quad core 3.3 gig  i5 with 1 gig gfx and it seems pretty good to me. That's reasonable specs these days, but not exceptional.

I'd be against using an image for a drop menu background in a default theme. IMO it gets too messy with the need to have things expand in two dimensions. Not that it can't be done, but I'd prefer not to.

CSS3 transtions though are a definite possibility. I've just been using them myself and although stupid bloody IE wont support them (of course), everyone else does. I'd be ok with using them for most browsers, and just calling js as an accessibility fallback for IE.

Oh speaking of transitions, what I want to play with next (will sort it next week, most likely) is getting keyboard accessibility working with transitions. You can cycle through the links easily enough while checking url's in the status bar, but that's not really all that great for the average user. It'd be far better to have good visual representation of the menu options via keyboard.

The current menus do that via js, and I've already done it for sans-js by adding a bit of css here and there, but I think it should be quite easy to add a fade transtion into the mix.

The plan is to use z-index shift instead of a left positioning shift for hiding the drops, and use rgba transparency* on the relevant elements, along with relative positioning on the submenu li's and absolute on the anchors. This should allow repositioning the anchors in the stack and transitioning the colour properties on focus. I'm already running the z-index and fade combo on the site I admin, and it works very well. I just have to throw in the extra tweaks for good visuals via keyboard.

I've gone with the z-index idea because using left positioning in combination with transitions gives a really nasty effect IMO, unless you get excessively complex with the specifications of the transitions. I know some people have been playing with "cool" ways of making left-positioned menus transition into place, but IMO they're about as cool as blinking text and destined for the same fate. A simple z-index shift is much cleaner in practice.


*Because using opacity would force inheritance on all child elements, whcih would make visibility on focus impossible.