I'm using Adobe Dreamweaver CS4 and I've decided to use Spry MenuBar for navigation, Spry CollapsiblePanel for some tables and SpryTooltip for some photos. Everything worked nice in off line view but when I uploaded it to Internet basic CSS (for text format, header, body area, footer etc.) was good but those 3 Spry effects somehow lost their code....for example, when on line Spry MenuBar is shown as vertical bulleted list, and other 2 have no effect either. I checked code, everything looks good but it seems that it's not good after all. What could it be, please help.
Well, what browser were you looking at the site in when the page was local, and which browser are you looking at the site in when it's uploaded to the server? If you say "it looked great in DreamWeaver" then realise that nobody surfs the innernetz in DW and it doesn't matter a hoot how good or bad any site looks in that... it's not a browser, it's a (horribly expensive) text editor. I personally hate Spry menus because they not only break horribly in IE out-of-the-box (I've fixed my share of them... by "fixing" I mean, I removed the Spry stuff completely and used a CSS menu instead, which unlike Spry actually works on all browsers all the time), but also they require Javascript to run. It's Bad Usability to have Javascripted menus, better to have CSS menus who have link fallbacks (for those who still can't get the dropdowns to drop down) and some Javascript sugar on top to smooth things out. Anyway if you've got a bulleted list, without seeing code we still don't know if it's really because your CSS is somehow getting blocked, or if it's a difference between browsers (IE and Firefox show floated list items differently, for example... FF may show bullets while IE doesn't, unless you specifically state "list-style: none;" on them). You'll have to either post a link or your code. Since it doesn't matter what your site looks like in DW, it's ok to just have your online code. After all, that's the version of the site you care about anyway : ) Since Spry is Javascript, if it ends up the problem is in the JS part of Spry, then questions about that specifically may have to be posted over in the JS forum.
Thanks for answering. When off line I previewed my web site in Firefox, IExplorer and Opera and everything was fine on all 3 of them and when I uploaded it on Net all 3 showed me the same mistakes meaning...no css in those 3 Spry's. As I see it's not a very good idea using them. Good, thanks, I'll try some other way than Spry's. I got a lot to learn anyway. Thanks for answering.
Ok, so mistake 1. ... and mistake 2 Wow, mistake 3? Do I need to say it? Mein gott, throwing enough rubbish libraries into the trash WYSIWYG? You've basically embraced how not to build a website, and that's without my even seeing it. Did you upload their big-ass library files? Are the URL's to them resolving properly? Though I'd have to actually see it live someplace online to diagnose why it isn't working. URL or nobody is going to be able to offer real help.
I'll go ahead and recommend the Sons of Suckerfish as a good HTML/CSS basis for dropdown menus. They actually still have one bug they have not accounted for: if you remove their Javascript for IE6, you may see IE7 also not working. This is because IE7 doesn't use the Javascript itself but the JS sitting in the <head> seems to help IE7 trigger something. I don't use the sfhover JS so I add this in for IE: li:hover { visibility: visible; } before any other :hover statements. Then, Blake Haswell has a nice little Javascript that adds extra keyboard support and a little bit of a delay for those shakey mouse users (he's got one bug that hits Mozilla and IE6 but it's easily fixed): http://blakehaswell.wordpress.com/2009/03/20/long-lost-nephew-of-suckerfish-part-deux/ I posted a fix to the code in the comments. He has a link to a live demo. Here's a page which started life with a Spry menu and I gave it a pure-CSS menu instead with some JS help for IE6 and Blake's JS for the hover delay.
@SP - Not wild about that hover delay - makes it look broken. Though the broken issue could also be the depth sorting issue I'm seeing of 'home' appearing atop the first hover. But then I'm a 'now' kind of guy - it's why I turn off all the goof-assed animations in every OS I use. When I hover or open a menu item I want to see it NOW, not three seconds from now after some goofy animation - at that point you might as well have a animated dog asking to 'help me' find what I want. My advice is to take and write a pure HTML/CSS menu, and just throw peterNed's Hoveranywhere at IE via the stylesheet - keeping all the 'legacy' crap out of the markup without the need for any extra classes or bullshit conditional comments. Here's an older one I wrote a while back (april last year) - I still use the same basic technique. http://battletech.hopto.org/html_tutorials/cssMenu/template.html Directory is unlocked http://battletech.hopto.org/html_tutorials/cssMenu So you can take a look at it's bits and pieces. A HELL of a lot cleaner than suckerfish - much less the fatter entirely javascript based menus.
I don't notice it as I surf with JS off anyway, but mostly the purpose of it is for jaggitty mice: people shouldn't lose their menu depth because their mouse was off the menu for a split second. Menu should have no delay on-hover, only off-hover. Something I appreciate when I use my husband's computer, where the mouse does not move the way you intend. Actually, it seems to be a good parkinson's/palsy imitator/tester, like those cars kids can drive that simulate drunk driving, cause I seriously can't use most drop-down menus with my husband's mouse, esp if they go more than a single level deep (which in general is Bad Usability but I did not have the freedom to rearrange the menu in the above case, only recode it).
I've stopped using dropdowns on most of my designs for the very reasons you just listed... though I've found the best solution to help 'twitch' users is to just increase the top/bottom padding of all the menu items - more area, less prone it is to breaking from moving the mouse.
Which is the reason I'm more okay with the "mega" dropdowns. Multi-levels without the mouse gymnastics, though you still need JS enabled if you're keyboarding.