Put your ASP.NET menu on a healthy diet -- introducing the lightweight render mode for RadMenu

I like to regard the changes in classic vs. light-weight rendering of the menu as me before and after shaving -- same fine looking chap, but twice as many ladies turn heads.

If only the changes were a handful of beard...

First glance

At first the menus look mostly similar. The only difference seems to be that lightweight menu takes full screen width and the vertical bars between the root items are monochrome instead of embossed. Hovering items will also not reveal any viable differences.

However, if you click on an item, you will notice a slight inner drop shadow in the item. That shadow, or halo, is persistent across all focused items and available to all skins and is a hint to the currently focused, or active, item.

Fig 1: First look of lightweight (top) vs. classic (bottom) rendering

Markup and CSS

The end user markup is quite trim -- we tried to remove all extra markup (and we did quite well). First we removed all the decoration elements for shadows and rounded corners. Depending on the exact configuration of the menu that's about 300 bytes of HTML per menu popup, some 5 KB base styles and a medium of 4 KB per skin. Compare classic rendering:

vs. the lightweight rendering

Don't like the way rounded corners look, or you need to tweak the shadows? That's a couple of lines of CSS now, compared to a couple of image files and a dozen lines of CSS for the classic rendering:

Fig 2: Customize the shadow and rounded corners of the menu with just CSS

Proper markup

Ever wondered why we keep rendering link tags in the menu, even when there is no navigate URL specified? Wonder no more -- we render span elements instead of links when no URL is specified. Technically that adds a bit of HTML consider <a></a> vs. <span></span>, but that's just technically. In reality we shave off 3 more bytes per menu item and we are using the correct element.

Again, classic vs. lightweight:

Conditional rendering

Consider the following dilemma: what's the easiest way to get text of the item <a><img src="...">s<u>o</u>me text</a>? Well there isn't an easy way... For some of the client side functionality to work, like changing the text of a menu item dynamically, we need a container around it. However, if there isn't a picture or extra children, we don't need an extra wrapper. So again, depending on the exact setup of the menu that could be some 28 bytes per item:

Eye candy and sprites

As with the rest of the new controls and reworked existing ones, the primary candy comes from CSS gradients (more on that in a minute), and the actions sprite used widely in other controls. There is a good chance that if you already loaded the sprite once, no additional images will be loaded on the page. If your browser supports CSS gradients that is.

Oh, in case you need to make the menu a bit more colorful, say rainbows and unicorns style, you can do so quite easily:

Fig 3: Rainbow menu

Not just a pretty face

Following my initial observation for the menu, if I may, we didn't just shave off a ton of markup, we also added a few things to aid developers in extraordinary situations.

Let me ask you a rhetorical question: how do you open a sub menu? Me personally, I open it either be clicking or, if the bloody thing decides to, by hovering. (In that order.)

Let’s complicate the example a bit -- what about opening menu on touch capable devices with no mouse pointer? Err... Touch? OK, but what if the menu item has a link / command associated and you just triggered it!

Now that is an extraordinary situation and for that we have the toggle handle.

What? The toggle handle, you know that arrow / chevron looking thing that when clicked opens the sub menu. Wait, didn't we have that like for ages? Yeah, but it was more of an indicator before and now is a separate element that you can click on. Think Windows7 Start menu style.

Fig 4: Menu with toggle handle (top) and without toggle handle (bottom)

The sole purpose of the toggle handle is to provide users with a way to expand the menu in the unlikely situation that the menu they are interested in happens to have a link or command.

Make no mistake; while powerful in some situations, the toggle handle can prove a worthy adversary in the rest of the cases. Use ShowToggleHandle="True" with caution.

Want more?

So do we, but we need feedback as usual. We do have some ideas for the lightweight rendering:

• use prefix free gradients to make styles even trimmer;
• consider breaking the actions sprites in smaller chunks to optimize load;
• streamline the behavior of the toggle handle;
• evaluate current features and possibly retire some (just for the lightweight rendering)...

If you have another idea, please share it either here in the comments, or in the feedback portal.

And before we part our separate ways, I would like to give you the following food for thought on what we are preparing for the next release: after you obtain the 2013 Q3 release, just put a menu on the page, set the RenderMode to lightweight and add this line of CSS to your page html .RadMenu_Default {font-size: 20px;}. Not too shabby, eh?