Forum Moderators: open
flash would be rock solid - assuming the visitor has the plugin, and the menu doesnt have to physically cover any other content.
<edit> standing corrected - see below :)</edit>
[edited by: benihana at 1:37 pm (utc) on Mar. 30, 2004]
[udm4.com ]
UDM is a lightweight and accessible javascript menu, which provides useable content to all browsers - including screenreaders, search-engines and text-only browsers.
UDM is a lightweight and accessible javascript menu, which provides useable content to all browsers - including screenreaders, search-engines and text-only browsers.
I'm not sure what you think of when you see the word lightweight, but about 1500 lines of code in the main section (once you put back in the linebreaks in the code) of js is not what I would consider lightweight.
50 to 60 lines would be lightweight. It also doesn't work at all in Opera 6.
UDM is a lightweight and accessible javascript menu, which provides useable content to all browsers - including screenreaders, search-engines and text-only browsers.
Arrrggghhh! That site crashed my IE twice! At first I thought maybe something happened in the background. I then rebooted, went back to the site to test the functionality of the menu and wham, crashed again.
Thankfully I've figured out a way to stay away from all that JavaScript and DHMTL stuff. Not user friendly if you ask me, not for most applications anyway.
Lightweight? What exactly is lightweight about all of that JavaScript?
<added> I figured I'd give it one more try. Crashed again. Also, the author claims that it passes WCAG Triple-A when in fact it does not.
[webmasterworld.com...]
that script can be cut down dramatically, not including comments, to about 60 lines of code, and it works better than udm4, and can be made to work in all modern browsers, including ie4 and ns4 with only relatively minor modifications.
There is absolutely no reason to require 40 kB of code to turn on and off an element's visibility, plus basic timer function, which is basically all you are doing on a decent drop script.
I also tested the udm4 on a slower pc, IE 6, the results were, as expected, horrible, since there is far too much js and css running, the menus just barely work, I've tested modified version of the blobfisk ones I'm using on the same setup and they work instantly, I'd say 10 times faster, at least.
I... created a menu bar with nine links (2 gif images for each - a different color for the rollover... is it the best solution or is there a better, more efficient menubar solution?
My menubar with the header is 7KB.
I assume that's not including the graphics. A CSS formatted page, minus the text content, runs around 5kB, give or take, for all the HTML on the page, and is radically more search engine friendly.
using display:block on the navigation links, with a:hover events changing background color, gives a completely adequate rollover affect
Take a look at UDM3 - it's a more basic version for older browsers.
Sounds like you're friends with these guys, why would I spend more time on something that is that bad, poorly done software doesn't make me want to look at more of a company's product. I'm not a fan of licensed Javascripts, the idea is really weird to me.
I don't suggest UDM3 or 4 are the best, only that we need a menu at work that runs in Netscape 4, so UDM3 fits the bill.
I also took the time to pass on the comments from this thread. The programmer wishes to make the following reply:
"I'm not sure what you think of when you see the word lightweight, but about 1500 lines of code in the main section (once you put back in the linebreaks in the code) of js is not what I would consider lightweight."
Okay - but you don't put back the line breaks - you run it concetenated as it is, and it comes to just under 20K for the main script. That's not tiny, but it's smaller than most DHTML menus. Not as small as something you custom-wrote just for your site, but inevitably, an API can never be as small as a custom script.
"It also doesn't work at all in Opera 6."
The navbar is there, but the menus don't work, no. That's because Opera 6 doesn't support dynamic display, and visibility alone is not enough - invisible objects still take up screen space, so large menu structures would create unecessary scrollbars even when closed.
"Arrrggghhh! That site crashed my IE twice! At first I thought maybe something happened in the background. I then rebooted, went back to the site to test the functionality of the menu and wham, crashed again."
I'm sorry to hear that - could I ask you to email me at cake@brothercake.com with the details, so that I can try to root out the problem that caused your browser to crash?
"the author claims that it passes WCAG Triple-A when in fact it does not."
Can you back that up - what accessibility issues have you found, or in what way do you not think it meets AAA conformance?
"There are almost 40 kBytes of javascript code in that. That's so absurdly bloated,"
The developmental version is 40K yeah, but you don't use it like that in production - once you remove the comments from the custom file, and use the built-in CSS generator to convert your config into plain CSS instead of using the JS-generated stylesheet, then it averages 30K. If you don't use the optional keyboard navigation module, then it comes down to 25K.
"a drop menu script that works in everything, always, with the same accessibility features was demonstrated by blobfisk here:"
Okay - that's a script which provides timed visibility toggles - that's the core of a menu script yeah, but it's only the core, in the way that a carburetor is not the whole car. You still have to style and position the menus, provide rollover behavariors if you want those, and make it look and behave consistently cross browser. I'm not critisizing that script - but it isn't a menu script, it's one component of a menu script.
It also isn't as accessible - the majority of screenreaders cannot see content which is hidden with visibility - if you use that code (or indeed, the vast majority of all menu scripts) you'll have the same issue - screenreaders can't access the menus.
Mine doesn't have this problem, because there's more than simple display and visibility toggles behind it.
"There is absolutely no reason to require 40 kB of code to turn on and off an element's visibility, plus basic timer function, which is basically all you are doing on a decent drop script."
There's a lot more to a professional menu than that. How about:
- synchronised *open and close* timers - so you can move your mouse over intervening links on the way to a menu, and the menu you're going to won't close
- dynamic insertion of submenu indicator arrows
- full keyboard navigation using regular arrow keys as well as Tab
- menus which dynamically reposition themselves so that they're always inside the window
- cross-browser dropshadow effects
- dynamic creation of "iframe shim" layers so that the menus can go above <select> elements in Win/IE without having to hide them
- fully controllable styling over all menus and links, which looks the same in all supported browsers without you having to think about cross browser CSS
- a proper semantic structure - the whole thing is a transformed <ul> so it provides structurally meaningful content to legacy and text browsers, and useful semantics to screenreaders and other access technologies
- a two-way API that reports menu events and objects to user scripting, and visa versa - this allows developers to write external extensions that modify the menu's behavior, or tie in other processes such as speech output
- proper event encapsulation - other scripting is not affected, including other window.onload functions
- detects unusual browser states such as stylesheets being disabled, or colors turned off in IE's accessibility options, and modifies the menu's behavior to minimise usability problems
- supports controllable flexibility of a horizontal navbar - it can remain rigid, or collapse into multiple rows as the window size decreases
- it works with XHTML served as XML
All attitude aside - if you think you can do all that from a semantic <ul> structure, and do it in 25-30K of production code, then be my guest - you'll be the second person ever to have managed it, and I'm sure the market's big enough for both of us :D
"I also tested the udm4 on a slower pc, IE 6, the results were, as expected, horrible, since there is far too much js and css running, the menus just barely work"
Again - if you'd be so kind as to email me with the details, then maybe I can improve the situation. It might just be that turning off the transition effects makes it work acceptably fast, but either way, I'd very much like to know so that I can make it better.
I'm sorry to hear that - could I ask you to email me at cake@brothercake.com with the details, so that I can try to root out the problem that caused your browser to crash?
IE 6.0.2800.1106 on Win98
Window froze. Could not Ctrl + Alt + Delete out of the window. Ended up with the blue screen of death (a fatal exception occurred). Had to reboot to regain control of my system.
Can you back that up - what accessibility issues have you found, or in what way do you not think it meets AAA conformance?
A quick check using Bobby and it showed that it failed WCAG Triple-A [bobby.watchfire.com].
Okay - that's a script which provides timed visibility toggles - that's the core of a menu script yeah, but it's only the core, in the way that a carburetor is not the whole car. You still have to style and position the menus, provide rollover behavariors if you want those, and make it look and behave consistently cross browser. I'm not critisizing that script - but it isn't a menu script, it's one component of a menu script.It also isn't as accessible - the majority of screenreaders cannot see content which is hidden with visibility - if you use that code (or indeed, the vast majority of all menu scripts) you'll have the same issue - screenreaders can't access the menus.
Since this is a for profit venture, I'm not interested in helping debug problems for the developer, especially since it's such a unpoetic piece of work. The first recommendation struck me as a pretty obvious attempt to promote a commercial product, and a quick look at the product revealed flaws that didn't warrant this kind of recommendation.
Since you are putting this out as a 'professional' solution, the number one requirement for a professional product is stability. The first two users here who tested your product found instant failings and shortcomings. That's two testers. Two failures. That's not what I call stable, sorry.
UDM is a lightweight and accessible javascript menu, which provides useable content to all browsers - including screenreaders, search-engines and text-only browsers.
Notice, two out of these three statements are not true. It is not lightweight, and it does not present useable content to all browsers. This is a bad way to present the product, it's dishonest.
The blobfisk javascript is complete, and works better than the udm4 script, and is at the very least 10 times faster, probably a lot more than 10 times, there's really no way to judge since it's instant on even the slowest pc I've tried it on, I'm sorry, but I've tested both, if you don't like that result, that's fine. The reason I took the time to look at the blobfisk menu is it's the first stable, user friendly, understandable, unbloated, and very flexible script I've ever seen.
You give the analogy of it being the carburetor only, that's not right at all. It's the engine and drivetrain. The features that bloat udm4 are things like air conditioners, cupholders, rotating mirrors etc. The engine is what makes the main thing run.
Since a well implemented menu needs only relative positioning, that's not an issue. The rest of the blobfisk code comes in the CSS, which is not that much for a simple display.
30 kB of javascript is bloated code, that alone would take 6-8 seconds to load over a dialup connection. Most of the features that bloat that code are exactly the features that make it work poorly, so I wouldn't consider those an advantage, just the cause of the bloat.
Saying removing the linebreaks is what makes it 1500 lines long is well, what can I say, the code is 1500 lines long. You have to have a way to judge program length, and linebreaks are the way you do that. I could make an HTML page with no indents or linebreaks and brag that my page is one line long, please be serious in your response. Your code is 1500 lines long, and that's only the main component, the blob fisk one is about 70-100 lines long, for all of the javascript.
Screen readers read the blob fisk code fine from what I can see, it's the same logic, hardcoded menus on the page, they are there, except when done well they are also in the right place on the page, under the link they belong to.
In fact, I tested it recently using Opera 7's handheld device emulation, and even the on off feature worked, which amazed me.
the visibility problem you have is because you are not z-indexing correctly.
Because these bloated drop menus really bug me, as does licensed javascript, I think I'll have to build a nice, user friendly version of the blobfisk thing that will install fairly easily, and release it open source, hopefully after a while people will start to realize that you can have a really well functioning menu system using code that actually is truly lightweight, easy to read and modify, maintainable and stable, and that doesn't drag down page performance.
I'd say the main problem with a nice, clean, simple, elegant script is you can't try to make a living off of it. If I were to recommend a pay to license menu system, it would be the milonic one, since that one has always had awesome crossbrowser support, and the code is if I remember right, completely readable. It's bloated too, but it's fast, and works very well. And he made it work in Opera 6 almost as soon as Opera 6 came out, and didn't offer excuses as to why that couldn't happen. Making the milonic one have the accessibility support is just a matter of hardcoding in the menu container, I haven't looked at his most recent versions, he might be doing that already.
[edited by: isitreal at 10:29 pm (utc) on April 1, 2004]
Sounds great to me. I was using "AllWebMenus" (because, I confess, I haven't yet learned javascript) and it was a nightmare. Menus all over the place with different browsers and it completely wrecked havoc with folks with the OS 9 operating system -- site crashed and everything was jumbled. I wasted hours trying to come up with a fix but eventually just abdandoned ship. Are CSS menu bars as browser compliant as images based manu bars (would they work on Direct TV for example?)
Are CSS menu bars as browser compliant as images based manu bars (would they work on Direct TV for example?)
Smart question. The answer is a little gray. If you simply need the links to work, the answer is yes.
If you need the page to look almost identical in all cases, the answer is: if you use the right techniques, it will look almost identical in all cases. If you use the wrong techniques, like using inline ul li displays for horizontal navigation bars, then it will look pretty bad in some cases, like ns 4, ie 4, and older mac stuff, can't say about direct tv, but will still work.
If you put the navigation in a table, it will look almost identical in all cases. If you are looking for above 99% rendering for the page without losing much display quality, you have to use a table for the navigation.
If you are willing to sacrifice some quality, you can use a mixture, or a list of nav links with ¦ separators, that will bring you very close to 99.5 or more support.
But if you use full css to make the bars, you get a huge jump in performance, better search engine results, better spidering of your site, faster loading pages, so I'd say it's worth it no matter what techniques you use.
Menus all over the place with different browsers and it completely wrecked havoc with folks with the OS 9 operating system -- site crashed and everything was jumbled.
The sad truth is that it only takes about 60 lines of well written code to make a really great, reliable, stable, fast drop menu. Everything else is just extra junk that has nothing to do with the core functionality of the product, and as you can see from this example, actually detract from it.
I refused to implement drop menus because of this kind of problem, it was always something, positioning, instability, whatever.
The blobfisk menu, with modifications that I guess I'll have to post at some time, worked perfectly the first time I implemented it, with one exception, moz 1 and less, but that was my error, I've fixed that. It currently works on all browsers above netscape 4 and IE 4, and with I think about 6 more lines of code, give or take, I could make it work on ie 4 and ns 4 as well.
All a drop menu is is a piece of html that is being turned off and on, that's it, period. Everything else is just extra baggage, sort of the modern OS philosophy of throwing in everything but the kitchen sink, but the problem is that javascript runs really slowly on computers because it's such a high level programming language, so you can't bloat it out and expect very good results. Plus the more code there is, the more likely it won't work in browser x or y.
The programmer wishes to add these comments.
"A quick check using Bobby and it showed that it failed WCAG Triple-A."
Firstly, those two errors it flagged are on the main page and nothing to do with the menu. And secondly Bobby is wrong in both cases - "onclick" event handlers *are* device independent, and text boxes *do not* require default placeholding text anymore. Bobby is not a reliable validator; I would not advise you use it for anything. I'm happy to listen to real accessibility problems, but Bobby's report is wrong.
I'll certainly check out that crash bug though - sorry it inconvenienced you.
At the end of the day - do you all really think I would publish a script with that much code if it wasn't necessary? You think it's bloated and unecessary and the same could be done in 10K or less? You really think so? Well prove it - there's big dollars in it if you can.
do you all really think I would publish a script with that much code if it wasn't necessary? You think it's bloated and unecessary and the same could be done in 10K or less
If you look at what a drop menu is, which is a piece of HTML that turns off and on, all other features are bloat. The bloat is how you sell the product, by saying, oh, but look, it supports feature x, y, and z. This is the luxury car type logic, add feature after feature to justify the high cost and profit margin, when a normal car will do the basic job just fine, with the plus that you can actually work on it yourself if you are so inclined, since you can accesst the engine without having to dig through piles of extra junk (since you are fond of car analogies).
But none of those features are really needed. That's the definition of bloat, it's why windows is always accused of being bloated, and why they always respond in the same way, oh, but how could we offer all these features if the code wasn't that big, which is begging the question, since it's the features that are the bloat.
In non javascript programming this programming philosophy is OK, since you are dealing with very fast execution of the code, and generally have good control over the runtime environment, with Javascript this logic is not ok, since you are dealing with very high level code execution, the highest I think anywhere in terms of code inefficiency, and you have almost no control of the runtime environment.
Obviously I wouldn't want to create a bloated product to do a simple thing, that's a waste of time, I'd rather have a clean, simple product do its thing elegantly. This simple logic seems to too much for the programmer to grasp, since his response suggests we should try to recreate his bloated product with less code. Why would I want to do that?
And anyway, in a few years this discussion will be completely moot, since anyone will be able to make a css drop menu that, except for a super basic timer function, will run straight through CSS, eric meyer has already made this as proof of concept, with no javascript at all, and once browsers support those techniques, that will be the end of this whole part of web development, thank heaven.
