Slashdot Mirror
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!"
Comment removed based on user account deletion
This is real support from the Hiermenus product. The actual 4.2.3 release of these menus is slated for tomorrow morning.
:)
Please note, the text of the article isn't fully complete yet.The complete copy will be posted sometime April 2nd London time. ElitusPrime jumped the gun a little bit in reporting this to Slashdot. Something about the Email I sent to him that contained the phrases "pre-release stuff" and "mix it [the final text] in with what's already there and you'll have a picture of what will be there tomorrow" seemed to confused him
Now *I* have to explain to an editor at Internet.com who doesn't know me from a hole in the ground why an incomplete article about an unreleased product is being slashdotted.
Happy birthday, by the way Elitus!
On to the menus.
Again, yes this is real support. For those of you with Konq 3.0 (it has been released in source form btw - the binary packages are being built right now) you can keep clicking the next article button to finally get to a page with a demo of the menus. They are rather impressive actually.
The Konq team has been working to get these menus to work for the past few months. Basically, I've been using them as a JavaScript/DOM/CSS test bed. Whenever I would find a problem with the scripts, I would report it to the kde-devel mailing list and go to bed. More than once, the problem I reported the night before would be fixed before I got up the next morning. Thanks especially to David Faure of Mandrake with his bug fixes and kind words of support.
These menus are *very* complex. They use an extensive collection of CSS, JavaScript and DOM manipulation to achieve the menu effect. It's important to note that for this release, the Hiermenus guys didn't have to change a single line of code in their scripts save for browser sniffing. Everything that these menus do now works in Konqueror out of the box (or out of the compile for those of you noting KDE doesn't come in a box). A big congratulations are in order for the Konqueror team for pulling this off. I'm proud to have been a part of it.
I plan on writing a story about these menus and what it took to get Konqueror to support them for dot.kde.org sometime in the next few weeks. This time, I'll tell Elitus about it *after* it's final...
David
JavaScript itself, thanks to its Microsoft "JScript" counterpart has been a cruel joke to we developers for years anyway. Just compatable enough to be able to work around the differences, but just different enough to be a royal pain in the ass to use for anything complicated.
-Pete
Soccer Goal Plans
When the font configuration data gets reset, or it can't find the default font (such as, if you are using bitmap helvetica as your font (which is the default), but using Xft rendering which does not support bitmap fonts), it goes to whatever is alphabetically first among the fonts it is aware of. Sometimes it ends up being Arial, which is ok (although its usually the wrong size), on my computer it typically chooses an absolutely horrid looking font called "Agate".
"(Man) tries to live his own life as if he were telling a story. But you have to choose: live or tell." --Sartre
If anyone's interested: www.brothercake.com has a JS menu, UDM, that works very well cross-browser.
And it's free-as-in-the-guy-who-wrote-it-says-so. Gimme-credit-ware.
I use it on the main page and the web-store for navigation. It can be slow on some browsers, but it's actively developed and gets better every day. I just checked it with konq 2.2.1 and Opera 5.0, no problems. In mozilla it's slow as hell, but I haven't tried moz 1.0 yet.
--J(K) DOS is like Unix in exactly the same way that a pinto is like an aircraft carrier.
Now.
You obviously have no appreciation for what is involved in the hiermenus package. I have used these in the past (version 3) and played around a bit with their new version 4. I would love to see you recreate what is involved in these menus in 5-10 days, much less 5-10 minutes. Hiermenus has all kinds of options for customizing appearances and layout, and autogeneration of all menus from simple paramater lists, among other things. Most important is how portable their code is. They went to great lengths to make sure these menus work in every browser, even that DHTML monstrosity of a browser known as Netscape 4.
If you are an expert at DHTML, maybe you could recreate a totally rough and basic version of these menus in 30 minutes. But to create something nearly as reusable and customizable as hiermenus, youd be hard pressed to do it in a week.
It seems to be a very common theme around here to put down anyone that tries to make a buck. Its really sad. These people have created a polished development tool, and all you can say is "thats nothing, I could do that". Maybe you could, but from a business standpoint its probably a heck of a lot cheaper to just buy a license.
For the record, I have no affiliation with the creators of hiermenus other than having used it in the past, and I have no incentive for promoting it either way.
DHTML menus depend on no events but the onmouseover and onmouseout events, which are the EXACT same in every popular browser since Netscae 3.0
Sure, as long as they are registered in the HTML. But if you try to register them in Javascript, you have the W3C "AddEventListener" method, and then you have the MS "AttachEvent" method.
There is no reason you should have empty divs in your code to begin with. Why are they there?
Who cares? The standard supports it, it shouldn't be broken, and it worked in IE5 and IE5.5 but broke in IE6. Far as I'm concerned, if it works in Mozilla it should work everywhere else.
I have no idea what bug this is. Vertical scrollbar bug?
Use window.open to create a pop-up. Set scrollbars=no. Create a background image that is the same size as the window client area. In IE there will be an empty, useless vertical scrollbar on the right side. The only way to get rid of it is to set scroll="no" in the element (a mind-bogglingly non-standard field), BUT then it leaves a fat hole in the page where the scroll bar used to be, so you have to set "margin:0" in the style sheet as well.
That bug took weeks to research and fix.
It doesn't affect DHTML menus directly, but it is an example of why it is such a gigantic pain to do DHTML anything, and why web sites cannot get past HTML 2 after four generations of browsers.
Hopefully Mozilla will fix this.