Konqueror's Javascript Continues To Improve
ElitusPrime writes "Konq's Javascript support may have been regarded as weak in the past, but 3.0 is a huge improvement. As an example, DHTML Lab has just released a Konqurer supported version of their popular HierMenus product. These cross-browser, backwards compatible pop-up menus are very complex, using all sorts of Javascript and DHTML tricks. Konq now supports them out of the box!"
Gotta hand it to ya, that's the most believable April fool's post yet!
c-hack.com |
I guess it's a good thing all of my web apps still use server-side appliction code for all serious error checking. Complete platform/browser independence has not been accomplished for even most of the major manufactures and platforms. Javascript could brobably be attributed to most of the errors on (poorly written) web pages out there.
Don't sneer at the K. It's always been a quality project. Yeah, it's short on features, but the features it does have work. Given the short time the project has even existed, it's pretty damn impressive.
Compare K with Mozilla, which after four years still isn't close to release quality (never mind the version number -- look at the damn bugs). This despite more resources, more time, more buzz, more everything. Face it, Konqueror is the surviving alternative to Internet Explorer.
The only complaints I seem to hear about Moz is that it won't render site X, which 9/10 times is do to poor coding on that particular site. Keep in mind, correctly rendering code != a bug. Quite the opposite actually.
Be strict with what you send. Be liberal with what you receive.
Dancin Santa
A Personal License is available for any non-commercial Web site that is less than 5 pages. The one-time licensing fee for a non-commercial Web site is U.S. $29.95.
For the DHTML code that is already in my browsers Window? I didn't sign any EULA by loading the page so what stops me from just modifying the code to my own purposes (and obsfucating it to avoid copyright stuff)?
I don't think this is an April Fool's joke, I just think this guy is smoking crack if he thinks he has any hopes of making money off this.
BTW: The only real news today was that someone wrote a JavaScript menu that works in Konqueror? I usually don't complain about article weakness but come on.
int func(int a);
func((b += 3, b));
I could code my own implimentation of this in 5-10 mins!
Then please do so. Post a link.
The Hiermenus are not "simple DHTML menus". They are extremely capable menus that work with an unprecedented set of browsers and capabilities, with good ease of use. They have been through multiple versions over the last few months, and are probably the best argument for the difficult of useful DHTML currently in existance. (This is how hard it is to create cross-platform menus, fer pete's sake... can you imagine creating a grid control?)
As simple as they may seem, they required an unbelievable amount of time to create because of the immense number of browser incompatibilities that exist on the their target platforms. Example: I once implemented my own menus, back when there was Netscape 4.2 or so, and IE 4 was reasonably new.
Several months after we'd rolled these things out, I got a call from upstairs, saying the menu looked wierd on their machine. "What version of Netscape are you using?" "4.5". (Numbers in the post are made up, because I don't remember the exact version, but the point holds.) "That's wierd, it looks fine on my machine."
Come to find out that in Netscape 4.5, but not Netscape 4.43 or Netscape 4.52, the code that decided how large a 100% height DIV was changed slightly, was causing (incorrect) shrinkage on their system, and was causing a background image to show up way too many times, making it ugly. Eventually I just let the bug stand, and to this day, if you hit the site with the wrong version of Netscape 4, the menus are ugly.
These things multiply the more browsers you add into the list of supported browsers, and that list is long for hiermenus. While we may wish they were free for hobby sites, purchasing a license in a more formal environment (not necessarily even corporate) is giving you hundreds of hours of dev time at a very cheap price. It's literally cheap at twice the price.
They are not wacko. The wackos are those who in a corporate environment look at them, make the same call you did ("I could code that in an hour!"), and proceed to blow thousands of dollars worth of time to save themselves 30 bucks. (Money, people, money. Learn about it. There are few things as valuable as a technically-savvy person who understands business!)
Does anyone know if the Konqueror (or KDE in general) is improved regarding Fitt's Law adhesion? KDE usability would go all the way up if the rule is followed whereever technically possible.
To suggesting that due to the faults of javascript imlementations you still do server-side validation is entirely the wrong way to look at it. You should always do server-side validation. Where possible you should also do client-side validation to avoid a round-trip to the server but that's a usability issue more than anything technical.
I completely agree with your last sentence, though! :)
Drop-Down Menus: Use Sparingly
:)
Summary:
"Drop-down menus are often more trouble than they are worth and can be confusing because Web designers use them for several different purposes. Also, scrolling menus reduce usability when they prevent users from seeing all their options in a single glance."
And I really agree with them. Don't use menus at all. Save your end users' valuable time (and time is money) by just hiring someone sane to develop a simple page. Like Google's page -- everyone can use it
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
Popups are evil. Well, evil if you dislike their behaviour in your desktop environment. And as we all know, they can be abused if the browser isn't very tightly in control.
I want to have control over my desktop. If I stretch my browser out to 800x600, then I don't want any popup to wander out of that range. The best way I see to do this is to implement the browser so that all dynamically created menus and popups are entirely controlled by the user, when the user choose to exercise that control. And they should be parented within the existing window unless the user allows or requests otherwise. Many kinds of DHTML do that now, but the way it should be is DHTML, Java, and Javascript cannot cause any new windows to every pop up outside of the existing window. If you have to bring up a menu, do it within the confines of the browser window itself. And this has to be part of the browser implementation, and not left up to the site to decide (as some will abuse this, we know). I haven't had the chance, yet, to try out all the new browsers around. Eventually I will, and hopefully some are going the good direction.
now we need to go OSS in diesel cars