Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
KDE GUI

Konqueror's Javascript Continues To Improve 173

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!"
This discussion has been archived. No new comments can be posted.

Konqueror's Javascript Continues To Improve

Comments Filter:
  • ha! (Score:4, Funny)

    by wrinkledshirt ( 228541 ) on Monday April 01, 2002 @09:37PM (#3268444) Homepage
    Now there's an april fools joke.
    • Re:ha! (Score:3, Funny)

      by flewp ( 458359 )
      Konq now supports them out of the box!

      It must be a joke, I bet Konqueror doesn't even come in a box.
    • i am glad to have REAL news back... i haven't read anything all day with all this april fool's nonsense.


      • Are you sure? I mean these are all the articles that were posted on April 02. Yes I am not in the US!

        Konqueror's Javascript Continues To Improve KDEPosted by Hemos on Tuesday April 02, @11:06

        April Fools Wrap Up It's funny. Laugh.Posted by CmdrTaco on Tuesday April 02, @09:29

        Blizzard removes Orcs from Warcraft III GamesPosted by CmdrTaco on Tuesday April 02, @08:36

        Linus Retiring from Kernel Dev LinuxPosted by CmdrTaco on Tuesday April 02, @06:49

        CPAN Shifts Focus JavaPosted by CmdrTaco on Tuesday April 02, @05:55

        Wil Wheaton to get new role on 'Enterprise' TelevisionPosted by CmdrTaco on Tuesday April 02, @04:43

        nVidia/AMD Merger Announced AMDPosted by CmdrTaco on Tuesday April 02, @04:05

        Developers: Rootkit Packaged for Debian DebianPosted by CmdrTaco on Tuesday April 02, @03:21

        Apple: Mac OS X Secrets of the Elite OS X (Apple)Posted by CmdrTaco on Tuesday April 02, @02:31

        Updated Slashdot Advertising Policy Slashdot.orgPosted by CmdrTaco on Tuesday April 02, @01:43

        Google's Pageranking Explained The InternetPosted by CmdrTaco on Tuesday April 02, @00:59

        AOL Buying Up Blogs America OnlinePosted by CmdrTaco on Tuesday April 02, @00:16

    • Javascript is a joke! Ha Ha! Konqueror supporting something! Who thought of that?

    • by jsse ( 254124 )
      Now there's an april fools joke.

      It isn't?
  • Gotta hand it to ya, that's the most believable April fool's post yet!
    • I can't agree! I knew this one was fake before I got to the first line!

      What the hell is Java-"SCRIPT"? and "D"-HTML? It's disturbingly clear that the moderators have just gone off their rockers!

      I mean, first off, what idiot would name a web browser "Konqueror"? And "Free" (as in cocaine) software doesn't come in a "box", it comes in delicious tarballs that are good eatin'!

      Look at all the idiots taking this seriously... lol freakin n00bs.
  • Konquerer can yet do Java..Ha ha..APRIL FOOLS!!

    Oh..wait..
  • Mirror (Score:3, Funny)

    by Alan_Thicke ( 553655 ) on Monday April 01, 2002 @09:38PM (#3268454) Journal
  • Nope, the anonymous posting hasn't returned. So nothing can be real yet!
    • Re:Ain't Real (Score:2, Insightful)

      by billstr78 ( 535271 )
      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.
      • Re:Ain't Real (Score:1, Insightful)

        by Anonymous Coward
        Er, standards wise it's nothing to do with manufacturers. They're under no obligation to write a browser with javascript support.

        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! :)

    • Go ahead and mod me as troll but...

      Lets hope it never does

      Anonymous coward is a good name for them

      Even though you could setup an account with a bunch of B.S.

  • Forget Konqueror, I want CSS and Javascript for Lynx, dammit! :-)
  • Now that the destruction of 4/1 is over, can we move on with our lives?
    We must all continue in our routine. If anything is disrupted, THEY have won.
    Help stomp out editorial terrorism.
  • by CoolVibe ( 11466 ) on Monday April 01, 2002 @09:45PM (#3268472) Journal
    The KDE3 Konq _did_ get a workover. Read the mailing list archives. KDE3, when the stable version comes out (probably when it's a .1 release, KDE hasn't been that good with .0 releases), is going to be really _really_ good.

    I'm glad to hear it's looking this good :) Go KDE!

    And as for anonymous coward still being switched off... I don't seem to mind much.

  • Please, if you run konqueror, upgrade to the new version. It's bad enough trying to keep things compatible with all the netscape 4.7 users who refuse to upgrade.
    • Some of us are stuck with it. I know that in the Federal Government, at least where I work, we are "required" to use Netscape 4.7 for email and browsing. Of course, they let some of us IE users slide by, but for the most part Netscape is what people use.

      You want the Netscape 4.x series to go away? Write your Senator and get them to pass a bill to make all of the major departments upgrade to something...anything else. Please!
  • In other news, Microsoft announced they are releasing OfficeXP for Linux; and Disney donates $10 million to the EFF... When oh when will this day end...
  • April 1 is over (Score:2, Insightful)

    by fm6 ( 162816 )
    Am I the only one that noticed that /. AFD began and ended precisely at Midnight GMT?

    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.

    • I STRONGLY disagree. I have run Konqueror (which is an admittedly fine browser) next to Moz and I continue to use Moz (or Moz derivatives : go galeon). I even use Moz on win32 as opposed to IE. I have yet to see a piece of functionality it is lacking that I need.

      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.

      Anyway, kudos Konq team, keep up the great work, your one of the better projects among the open source world.
      • Age old maxim (Score:2, Insightful)

        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
        • They should have included errormessages in HTML when it started off. Do you think I want a C compiler where I don't have to close the brackets or not being warned about odd coding practises, or just leaving out main() and still being able to compile it as a standalone exe. No I don't.

          Life would have been easier for those bannerhackers, to bad they don't realise it.
          • Comparing HTML to a programming langauge is ridiculous. When's the last time you could still use a bit of software and the compiler could cleanly ignore newer code it didn't understand (say, like, XHTML).

            XML fixes most of the problems, but even so compliance is over-hyped. People think that so long as validator.w3.org passes you then you must have done everything right - when there can still be a million things wrong with your code.

  • by Theom ( 567303 )
    Even if, why not move away from eye candy, and make something usefull, like working support for the special symbols of Latvian, sure I can read Latvian web pages, but I haven't managed to write anything in Latvian under Linux yet. For me the KDE vs GNOME issue will be soved when one of them does correct support for Latvian wich I can use without messing around for weeks. So long I am staying with windows (and until I get my Ati-all-in-wonder showing some TV).
    Have a nice day.
  • About Konqueror's javascript support being vastly updated. The only site left that I have javascript problems with is atomfilm's screwy setup (the "watch film" links on the pages are some funky javascript routines that don't seem to work...the stderr text mentions an attempt at"'VBGetWindowsMediaVersion'"...)

    I'm using CVS from yesterday. The only problems I'm running into now are some oddities in kate (the text editor) and the fact that there's STILL not a version of the GPL Quanta that will start up for me so far...everything else is beautiful.

  • I went to the developers site but oddly enough I could not find an example of their product. -- Could someone post an example of these menues?
  • How can one provide out of the box support when their is no box?

    Dancin Santa
  • by vectus ( 193351 )
    using konquerer, the only way to stop the damn msdn ad from showing is to disable images all together.
  • by brunes69 ( 86786 ) <`gro.daetsriek' `ta' `todhsals'> on Monday April 01, 2002 @10:13PM (#3268552)

    I went to that site in the latest Konq CVS, and the menus worked great. But then I went on to read about this company.. 29.95 for the use of some simple DHTML menus on only 5 pages?!@?!? Higher license fees for mroe pages??!?! I could code my own implimentation of this in 5-10 mins! These guys are seriously whacko.

    • Not only that, but as far as I can tell, the damn menus don't work with Opera at all. Now, I know Opera's DHTML isn't the greatest, but other folk seem to be able to pull off dynamic menus for Opera. Sheesh.
    • Not stoned (Score:3, Interesting)

      What are you paying for?

      => the programmer time you don't have to waste reimplementing the wheel

      => not having to face the horrible realization that you're losing customers because your reimplemented wheel only plays nice in IE version x.y, and breaks or looks ugly on anything else. And wedges the browser solid on IE version x.z
      • Re:Not stoned (Score:3, Interesting)

        by brunes69 ( 86786 )

        Er, DHTML menus are very simple to do. One small section of code will make a DHTML menu that will work in any version of IE since 4.0, and any version of Mozilla / Gecko based browser, and any version of Opera or Konqueror. It is very simple CSS. IE's imcompatabilitys are a misconstrued legend. As long as you siwch with the W3C DOM, most script written cleanly will work.

        And adding a compatability layer for Netscape 4.x is trivial on top of that, that is the only area you'd spend your time, in Netscape 4 compliance. And even that would take no more than 15 mins. Are you saying it isn't worth 30 dollars (actualy alot more if you have more than 5 web pages) to spend 15 mins writing some code? If you're paying your web guy 130 dollars an hour maybe, by my calculations, it may not be worth it. But then again, you'd be bankrupt already for overpaying your employees so it wouldn't be a problem.

        • It's worth your time (assuming "your" = nonprogramming manager) to buy this to avoid having to go through N iterations of web guys to find the one who has done this before, and knows how to do it properly. As opposed to your typical web guy who's still wet behind the ears and fond of doing everything in Dreamweaver.
        • There is no reason to code it yourself, but there is no reason to buy it. There are plenty of sites out there that give dhtml menus away for free, with up-to-date browser compatibility.

          But, because I am a webdev, I hope they keep getting me to code it myself. Got to put food on the table somehow!
        • As long as you siwch with the W3C DOM, most script written cleanly will work.

          Until you try to use the event model. Then the proprietary stuff returns, through IE6.

          IE6 doesn't support empty div blocks either.

          IE6 STILL hasn't fixed the vertical scrollbar bug (from YEARS ago).

          These bugs don't really require a lot of extra code, but the research to figure out how to get past them can take days. Is it worth $30? Probably so.

            • 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
            • There is no reason you should have empty divs in your code to begin with. Why are they there?
            • I have no idea what bug this is. Vertical scrollbar bug? I have never had a problem scrolling in IE. And how would this affect DHTML menus?
            • Re:Not stoned (Score:3, Informative)

              by The Cat ( 19816 )
              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.
              • As per the first comment, any HTML elements written to the page either using document.write or using W3C's element.innerHTML = "" will be parsed immediatly, and any onmouseover="" attributes you have in your tag will as well. There is no need in IE or any other browser to use AttachEvent, unless you like making things complicated for yourself.

                As per the scrollbar bug, this doesn't affect DHTML menus at all. And since that was the only comment I made to begin with, I don't see how this supports the arguement.

        • I could code my own implimentation of this in 5-10 mins!

          Then please do so. Post a link.

          Still waiting for that link to your menus. If you can do them in 10 minutes you should easily have them done by now...
    • The menus that do work in Opera are the equivilent of a div being revealed and hidden. The relation to the lovely hiermenus is only passing. Writing a hierarchial menu system isn't easy - and I'd love to see anyone here do better.
      • A div/span/layer/table being revealed and hidden is the only way to do hierarchial menus. If you look at the code for this you will see that is all this code is doing. You move a menu to a position, and reveal it. Then on mouse out it is hidden again. All there is too it. It's a joke.

        • I said it's equivilent. The emphasis was on the simplicity of revealing/hiding a DIV. Hiermenus are much more. They understand browser rendering bugs better than any other and they work around them for the users sake.

          If you can do better - I'd love to see it.

    • Lets not throw stones here... can anyone say they never "lifted" some javascript code from a site and put it in something they were working on - sans credit, copyright notice, GPL, etc?

      You want to write you own - do so. Lord knows we all have been asked to do this same sort of thing at one point or another. By charging a nominal fee - and it really is once you toss in docs, testing, and all the other nasty stuff no one really likes to do - it makes it easy to fold it into your company's codebase. I know I have contacted developers to use there code, paid them off, and embedded things like uploading into my apps. Not everyone wants someone elses name when they view source (grin)...
      • An even better way to fold it into your company's codebase if you are too lazy to do it yourself is to go get one of the many free (like totally free, do whatever you want with them) DHTML menu scripts from DynamicDrive [dynamicdrive.com], many of which I have seen have many more features than this one.

    • by Jerf ( 17166 ) on Monday April 01, 2002 @11:51PM (#3268754) Journal
      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!)
      • by Inoshiro ( 71693 ) on Tuesday April 02, 2002 @12:53AM (#3268945) Homepage
        Drop-Down Menus: Use Sparingly [useit.com]

        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 :)
      • by befletch ( 42204 ) on Tuesday April 02, 2002 @12:56AM (#3268958)

        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.

        And if you want more than just capable menus, check out Tibet [technicalpursuit.com], a full client-server architecture for the web. These guys started by using JavaScript to fix the bugs in various browser JavaScript implementations, and then proceeded to build class libraries, debugging tools, client-side page templates, and a full IDE. All in JavaScript. And I'm not making an April Fools joke.

        Also, the code is dual-licensed, commercial and open source.

        The code is beta at the moment, and there is much work to do, but this is a seriously ambitious undertaking.

        And no, I don't work for them or otherwise benefit from this heading-towards-off-topic post.

    • 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.
    • I have written a Hierarchial Menu script. And it took me quite a lot longer than 5 to 10 minutes.

      Let me assure all the posters saying "I can do it in 30 seconds flat, it's just hiding DIVs" that menus like mine and HierMenus are quite a bit more than that. Yes, it's true that you *CAN* make a single-level popup where the triggers overlap the divs work in IE5+ and NS6 in a few minutes. But if you want multiple levels of autogenerating, correctly highlighting cascading menus working in as many browsers as possible, it's a decent coding effort.

      You have to do everything 3 different ways for a start:

      document.layers for NS4
      document.all for IE4+
      document.getElementById for IE5+ or NS6, Opera etc.

      And that's just for getting references to page elements -- modifying them is another story entirely. Working around browser bugs takes anywhere from weeks to years -- I started the first version around Nov 2000, and am currently hacking away at the v5.1 script. Netscape 4 behaves differently with every different version, the platform of your computer, and it seems even the phase of the moon. Don't think about getting me started on IE on the Macintosh.

      Check my homepage [twinhelix.com], and navigate in, it's called "Cascading Popup Menus". It works in Moz, NS4, IE4+ and Opera 5/6, Ihaven't tested Konq but I'd appreciate feedback. (End Shameless Promotion :)

      For their price, it's probably pretty reasonable. Their menu is ~50k of JavaScript, mine is 12k but highly condensed. They used to give it away for free, as it was developed as a tutorial-like series of columns -- have a read through all the revisions before criticising Peter Belesis (the author).

      - Angus.
  • 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
    • Hmmmm... I look forward to hearing exactly how David *expected* me to interpret an email that said "Go ahead and submit the story to Slashdot." :-)

      Also to those who claim that they can reinvent these menus in a few minutes. I agree if you have v6 browsers. But these things work all the way back to v4 browsers. Plus they're tested on 30 something minor versions of the v4 browsers on multiple OSs. If you need to support older browsers, the menus can save you a lot of time and trouble. That being said, I do think the licensing scheme they adopted is pretty nutty. Who needs menus for five pages?!
  • Javascript is a joke (Score:2, Informative)

    by peterdaly ( 123554 )
    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
    • Frankly, I don't think you know what you're talking about. JScript et al went out the doors years ago; exclusing M$ tendency to embrace and extend. The remaining incompatibilities, usually faced when implementing DHTML, are not javascript specific. They are issues of the browser's DOM. Basically this means, as painful as it is to admit, Netscape 4 doesn't count. Netscape doesn't have a W3C compliant DOM. Never did. Why? The standard didn't exist. Netscape developed their own, JSSS (figure it out). Their proposal to have this be standard was rejected, and so they mapped what they could onto what they already had. Ever wonder why NN4 won't render style sheets without JavaScript enabled?
  • >Konq now supports them out of the box!"

    Hey, my Konq didn't come in a box!
    Did I get gyped again?
  • In response to increased advertiser demand, we have decided that we will post one story a day paid for directly by our advertisers. These paid "Slashvertisements" will appear daily amidst the normal stories you read here. Our first Slashvertisement is for our sister site, ThinkGeek, stuff for smart masses.

    That would make this the second Slashvertisement. And in other news, Mozilla, IE, and Opera continue to improve their products...

  • First of all: Thanks God april fools ended!

    This is great news. The more and more browsers evolute to have more features the better. Ive tried many times to search for contents on sites using some technologies only somehow understood by MS product (and sorry, they suck because if you build a table and dont close its ok), many many many times i had to start another search on goole in order to find another site that had the same content on different technology!

    So, who do we blame? Browser developer for not building their software bloated enough to accept everthing Internet Exploder does? Or webistes developers for closing their eyes for different browsers?

    I would say webdesigners could pay a little more attention and they could see that internet world is not build only on MS fundations. As a webmaster I had to say, 80% of our access is done by IE, 13% by Netscape and the rest is divided with more than 40 different browsers AND plataforms. Sure 1% of Linx users are not much, but this 1% could (for example) by a product that gives me much more profit than 80% of IE users togheter!

    I believe Konq gave a step foward, providing alternative ways to access these badly-built websites are great and the more they provide access to these one the more the normal user will start to use Konq (thou making it more famous - the more famous a product is the more the developers work on it).

  • by lkaos ( 187507 ) <anthony@codemonk ... s minus math_god> on Monday April 01, 2002 @10:35PM (#3268593) Homepage Journal
    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.
    • 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)?

      The law? Your conscience?

      The same things that stop people stealing any source code that is visible but not in the public domain (e.g. open source projects like Konquerer).
  • When is "Post Anonymously" coming back?
  • by KodaK ( 5477 ) <`sakodak' `at' `gmail.com'> on Monday April 01, 2002 @11:23PM (#3268681) Homepage

    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.
  • My menu code runs on several major websites. I would love to add support to Konqueror.
    What kind of DOM does it have ? Gecko compatible ? Links would be appreciated.
  • In anticipation of all the posts regarding the stupidity of charging for the code here's another site where all they require is a little copyright message in your code - Dynamic Drive [dynamicdrive.com].
  • it's Free Advertising Day?
  • I wish menuing was built into the browser using some XML specification that is implemented much like external style sheets.

    Too much effort is spent on developing human friendly navigation and requires the extraordinary use of "Javascript and DHTML tricks" that often break.
    • Very true. As web sites are more and more being referred to and thought of as applications, the need for an easy-to-implement toolkit to render and manipulate web-based GUIs is crucial. Something event-driven would be really nice too, so that maybe the screen-by-screen stateless interactions could be succeeded by more responsive methods and not require entire page reloads.

      I see a lot of potential in the Mozilla browser architecture, specifically XUL, for providing something like this. XUL provides many of the more complex and more powerful widgets necessary to desktop applications, and as Mozilla is about to reach 1.0, with AOL even examining its rendering engine for their product, a standardized XUL could really boost web application possibilities to new heights.

      This seems to be exactly where Java applets wanted to go, but failed due to its sluggishness, and it seems to be where Flash is trying to head also. I think we've all given up on Java in this space, but I'm excited to try the new Flash MX, with its built-in web widgets, and the new direction toward satisfying developer as opposed to designer needs. Because frankly, Flash 5 and under sucked if you were trying to develop anything but the tinyest applications.

      XUL and Flash are two quite different approaches to the same problem, and each offer different benefits to developers. XUL is open, cross-platform, and can integrate with the client operating system as part of the actual browser, but currently requires Mozilla or Netscape 6, which is only a few percent of the web. Flash is much more widely available, plus a smaller download for users, and acceptably cross-platform (NS6 has Flash for Linux, etc.) for most developers, but it's still more of a vector animation tool than a GUI tool, and as such can present an awkward framework for developers to work with, and its not open (although the SWF format is).

      Then again maybe things will change with the big web services push, or the "sematic web", or something new we haven't thought of yet (but some niece or nephew of Tim Berners-Lee has ;)).

      Anyway, since there is really no point to this post, I'll wrap it up now. I just think it will be interesting to see where things head, and which technologies shine, in the next few years. Just compare 2002 so far with 1998, it's a very different Internet for sure.
  • nothing starts out on top. I can think of a few other projects [kernel.org] that started out on the weak side but through the long process of trial and error and hard work, eventually proved to be worthwile.
  • Fitt's law? (Score:3, Insightful)

    by Wolfier ( 94144 ) on Tuesday April 02, 2002 @12:13AM (#3268798)
    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.
  • I wrote a mostly cross-browser (tested on Windows/MacOS 9 & X/Red Hat Linux, in Mozilla, Netscape4 & 6, Opera, IE5+) javascript/dhtml drop menu script. It's lightning fast because it renders the different menus to actual HTML divs instead of instantiating tons of JS objects, but at the expense of some customizability. Actually, you can still access everything in JavaScript, so the customizability is up to you. The best part is its less than 100 lines of JavaScript.

    Oh, and it's got an object-oriented PHP api, so you can hook it up to your database-driven sites easy enough. I wrote it because I found the others ugly to have to interface with PHP, and they all seem to slow the browser to a crawl (even on my AMD 1.4GHz w/ 512MB DDR-RAM).

    You can see it in action at this site [217.204.28.8], which is about to be re-launched. It's Open Source, but it's currently only downloadable through a package called Sitellite CMS [freshmeat.net], in the beta download. I'm preparing a new release of the core application framework behind this project, which is the Open Source part, which includes the drop menu stuff. That part is all contained in the 'saf' directory, and the drop menus are in lib/GUI inside that.

    If you don't want the PHP API, you're of course free to just take the JavaScript from the source on the link above.

  • Popups are evil (Score:4, Insightful)

    by Skapare ( 16644 ) on Tuesday April 02, 2002 @03:43AM (#3269309) Homepage

    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.

    • Yes, popups are evil. What does that have to do with this article though?

      Popup menus have nothing to do with opening new browser windows. In this context, "popup" menus means "menus like the context menu in desktop applications" (the one you get from right-clicking with the mouse). As such, "popup" is something of a misnomer, especially as it is so easily confused with popup window.

      Other than that, I agree - browsers allowing sites to open new windows is a horrible usability no-no.

      Cheers,

      Tim
      • When I right click, yes, that is a "popup". Some web sites have Javascript which pops up little windows to do some things like showing a selection of links or other resources. And as we know, some just pop these up with no user action for things like ads. I still call these "popups" despite the fact that the mechanisms in the windowing system is different for each. The concept is still the same kind of thing; the web can't do it using the same mechanism as right click does, because it doesn't have access to that API. If they could get to it, we know someone would, and someone would abuse it. I'm not confused about these because I use the term "popup" not for some specific mechanism, but for the overall general concept.

        What's needed is for users to select their own behaviour preference for different kinds of logical actions. The web site would then offer choices like menus, links to offsite pages, or whatever, and for each of these, the user can decide things like keeping in same frame (if framed), use whole existing window, or open a new window. And if opening a new window they should also be able to specify size restrictions, both a floor and a ceiling, either with absolute values, or values relative to the parent window.

        What I'd really like is for a way to resize this damned tiny textarea that Slashdot uses on the comments.pl page. Allowing us to set its size in login preferences would be better than now, but the best would be a browser that can give a right click option to "extract" the form element from the browser into its own window, which can be resized, or even allow resizing it right in the midst of the page (as if different sizes had been specified in the HTML). Also, textareas should have a "launch my editor for this content" option.

Two can Live as Cheaply as One for Half as Long. -- Howard Kandel

Working...