Drop Down Menus - HTML vs .js

[austtr]

I have a site where the user experience is best served by a multi-tiered drop-down menu. The choices were to use a DHTML app that compiles the menu data into .js files or to use a tool that outputs the menu data into HTML code.

The HTML option generates a HUGE volume of on-page code which I'd prefer to avoid. The .js option has just a couple of lines of code that calls an external file and all menu item pages get crawled and indexed via a row of footer links.

I've recently had a few experienced people look at this site to try and figure out why Penguin trashed it. All of them commented on the .js drop down as "maybe" a problem but were not sure and could not pinpoint any specific issues… more a gut feeling thing.

Anyone here with some experience on the pros and cons of .js drop-down menus?

[lucy24]

<tangent>

The HTML option generates a HUGE volume of on-page code which I'd prefer to avoid. The .js option has just a couple of lines of code that calls an external file and all menu item pages get crawled and indexed via a row of footer links.

I don't think it's that clean-cut. The ultimate code has to be about the same size, regardless of format. It's just a question of where the user downloads it from-- as part of the page, elsewhere on your own site, or a third-party library-- and whether the work is done in your server or in the user's browser.
</tangent>

Do the footer links exist independent of the dropdown navigation part?

[phranque]

have you checked that the .js file isn't excluded from crawling?

perhaps the "internal links" section of GWT will give you some hints.

google has gotten pretty good about recognizing javascript menus but i wouldn't depend on that.

[phranque]

It's just a question of...

it's worth noting an external file gives you the option of caching reusable code.

[FranticFish]

The HTML option generates a HUGE volume of on-page code which I'd prefer to avoid

I'd look for a better one. There are good pure CSS menus out there that use minimal markup.

See also [webmasterworld.com...] (blocked CSS & JS and Panda)

And finally: [youtube.com...] (Matt Cutts on footer links)

Matt Cutts "We do reserve the right to treat links in footers a little differently". Note that I think here he's referring to the 'sitewide' scenario, but I personally would consider spiderable footer nav an additional / secondary form of navigation, not the primary.

[Martin Ice Web]

Ipad can't show css drop down as there is no hover support! A workaround is needed. Did you think of a ajax menue? It is best for less traffic and overhead code , plus u can make it more variable dependend on the site u are on: think about siloing.
Keep. Hreadcrumps up for poeple not using js.

[FranticFish]

My dev guy recently built a pure CSS menu that worked in iOS for a project we worked on. Failing that you can use Javascript (or jQuery) to add 'onTap' to 'hover' events in iOS.

[Martin Ice Web]

@frantic i know that this will work. But jet this means much overhead, i keep up the question every time i redesign a site: what do i need for navigation? I see lot of overkill navigation and ask myself where is this usefull in regard of useness and traffic ?