Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Programming IT Technology

Seeking Good DHTML Debuggers? 103

christodd queries: "After years of programming in PHP and C++, I've finally delved into the world of Javascript and DHTML. The biggest hurdle I have come up against is the various web browser DOMs. I find that I spend much time googling for variable names, and guessing which variables do what. My favorite tool is a good debugger, and this is where I'm having problems. There is a commercial product by Netscript due out this quarter for $190.00, and there is a very young open source project at BiteSizeInc, but I have yet to find anything production quality. How does everyone else debug browser DOM issues?"
This discussion has been archived. No new comments can be posted.

Seeking Good DHTML Debuggers?

Comments Filter:
  • Venkman (Score:5, Informative)

    by TulioSerpio ( 125657 ) on Friday January 16, 2004 @07:45AM (#7996925) Homepage Journal
    Mozilla and Firebird come whith a Javascript debugger [hacksrus.com], and it works.
    • He beat me to it. I use mozilla for all of my Javascript debugging and have found it to work quite well. I don't see a need for any other.
      • Re:Venkman (Score:1, Interesting)

        by Anonymous Coward
        How well does it do at finding things that are going to mess up Internet Explorer? Some of us can't pick and choose what browser our customers are going to be using, you know.
        • Re:Venkman (Score:4, Insightful)

          by AKAImBatman ( 238306 ) <`akaimbatman' `at' `gmail.com'> on Friday January 16, 2004 @02:19PM (#8000818) Homepage Journal
          Simple. Mozilla and IE are compatible. I've been doing JavaScript for both of them, and when something goes wrong in IE, there's no good way to figure it out. So I launch Mozilla, bring up Venkman, and find the error lickety-split. Way better than IE's debugger with its imaginary line numbers.

          • Erm, the poster was asking when something that does work in Mozilla (& thus Venkman is ok with) does not work in IE.

            There is a free MS debugger, you'll have to search around for it though. I've had limited success with it, but at least it gives you a better idea of what the problem is than the standard IE errors.

    • Re:Venkman (Score:3, Informative)

      by Goyuix ( 698012 )

      For IE, I have found the Microsoft Web Developer Accessories [microsoft.com] a great help - especially if I can't remember document.form1.....

      They are said to only work with version 5, but I have had no ill effects of using them with IE6.

      And lastly, I don't think there is any one single tool that will do all the DHTML goodness you need (particularly if you are trying to validate it against multiple browsers). While you can separate DHTML out into JavaScript, the DOM, etc... each one really needs a separate tool to dea

  • by alanjstr ( 131045 ) * on Friday January 16, 2004 @08:13AM (#7997040) Homepage
    The Mozilla Document Object Model Inspector is very useful. It comes with Mozilla and Firebird.

    http://www.mozilla.org/projects/inspector/ [mozilla.org]
  • by seanmeister ( 156224 ) on Friday January 16, 2004 @08:13AM (#7997042)
    In addition to the Venkman JS debugger mentioned in a previous comment, Mozilla and Mozilla Firebird also include an excellent DOM inspector [mozilla.org] - very handy for page tweaking, "DHTML" or not.
  • My advice to you, is dont use Javascript , DHTML unless it is really neccesary. Its good for image rollovers and validating forms but the moment you try and do anything fancy with it like manipulating layers you will be plagued by crossbrowser incompatibilities.Generally speaking most of the dynamic content driven things can be done with your existing PHP / backend code.

    I have been developing websites for a number of years, and when I do have problems i have usually found that by typing "javascript:" into
    • by Jerk City Troll ( 661616 ) on Friday January 16, 2004 @09:29AM (#7997491) Homepage
      Its good for image rollovers and validating forms but the moment you try and do anything fancy with it like manipulating layers you will be plagued by crossbrowser incompatibilities.

      No, no, NO!

      First of all, do not use JavaScript for image rollovers. It's a terrible idea and the person who thought of using JavaScript for image rollovers should be shot. You never put images in webpages where the image is not the content. That's presentational HTML. Instead, follow this example [www.pixy.cz] which uses pure CSS. The basic idea is that you use the :hover pseudo-class to change the background property of a hyperlink. That background image can contain all states or it can be separate files. Wrap the inner text with a span tag and specify that span tags within the scope of your anchor tag get a display: none propety. Its so simple, it works without JavaScript, loads faster, cross-browser compatible, and if the user is running a non-graphical browser, it's still accessible. Here's a quick example (where somepic.png contains both roll over states, one at (0, 0) and the other at (0, 20):

      a.Foo {
      display: block;
      width: 100;
      height: 20;
      background: url("somepic.png") top left no-repeat;
      }

      a.Foo:hover {
      background-position: -20px;
      }

      a.Foo span {
      display: none;
      }

      Then in your markup, you put this:

      <a href="foo.html" class="Foo"><span>link to foo</span></a>

      Next, you should never rely on JavaScript to do your form validation. That's the most stupid, absurd thing I've ever heard. Leaving input validation in the hands of the client is to trust the user to not attempt to screw up your input. For forms to the useful, they have to be submitted to some kind of server-side logic. That is where the form validation should take place because then the user cannot side-step your input validation.

      Yikes. With people like you building websites, no wonder the Web is such a disaster today. Please change professions ASAP or read Designing With Web Standards [zeldman.com]

      • by edwdig ( 47888 ) on Friday January 16, 2004 @09:54AM (#7997664)
        First of all, do not use JavaScript for image rollovers. It's a terrible idea and the person who thought of using JavaScript for image rollovers should be shot.

        JavaScript was pretty much invented for things like that. JavaScript first showed up in Netscape 2.0, but CSS didn't show up until the 4.0 browsers.

        Relying on CSS isn't always the best idea - IE does a terrible job of handling it. When I do web development, most of my time gets spent trying to work around limitations of IE. Very simple CSS works in IE, but anything even somewhat complex probably won't work right in it.

        Next, you should never rely on JavaScript to do your form validation.

        Yes, completely relying on JavaScript for form validation is a very stupid thing to do. But that doesn't mean you can't do initial validation with it. If you click Submit on a form, and a JavaScript alert pops up to tell you that you have to enter your phone number, it's a lot nicer than if you get the error after the page submits.
        • I always find a server-side solution more graceful for the following reasons:

          1. The validation continues in the flow of the process.
          2. It calls out specific issues explicitly, in line with the field
          3. The other method doesn't work with ECMAScript disabled.
          • by lscoughlin ( 71054 ) on Friday January 16, 2004 @01:23PM (#8000153) Homepage
            This isn't a 1 vs the other value proposition.

            1. The validation continues in the flow of the process.

            and validation will continue in the flow of the process anyway. You use javascript to prevent a server roundtrip if possible and do the server side validation anyway.

            2. It calls out specific issues explicitly, in line with the field.

            Javascript can to, and server side script can fail to do this. This is a design/implementation issue.

            3. The other method doesn't work with ECMAScript disabled.

            Irrelevent. You're using validation on both ends. Where is this hardon against javascript you seem to have acquired come from anyway?

            -T
            • This hardon against javascript comes from the fact that half the sites I go to with JS tend to put a little alert icon on my status bar on one browser or another because something is broken. My hardon against it also comes from what I see in practice. I can't think of a site that I enjoy using that does js form validation. It really is a user side business logic vs server side business logic decision for me. I'd rather have a light page that loads quickly without an error, and I'd rather validate fields whe
              • This hardon against javascript comes from the fact that half the sites I go to with JS tend to put a little alert icon on my status bar on one browser or another because something is broken.

                The fact that the average web developer doesn't know how to write reliable, portable code is hardly an argument against the language that they don't know how to use.

                We've used JS client-side validation to replace apps used by data-entry operators that have very demanding speed requirements. Without client-side va

      • "First of all, do not use JavaScript for image rollovers. It's a terrible idea and the person who thought of using JavaScript for image rollovers should be shot"

        Maybe they actually stopped to think for a nanosecond and realised that some image rollovers and other animations may involve some logic depending on the state
        of the page or one of its components. The last time I looked CSS wasn't much good on complex boolean logic. Unless you know better of course...
      • Next, you should never rely on JavaScript to do your form validation

        Right and wrong. You can/should use JS to provide feedback to the client if they entered something blaringly incorrect (ie, left the last name field blank, formatted a date wrong, etc). You should, however, *always* assume the input coming to your back end is fiddled with and trying to break your system, so still have all input checking on the backend as well. Client side input validation is good because it gives immediate response to
        • Better layout and design would eliminate the problem for lower-end clients and turn-around time. Removing ECMAScript-based validation would lighten the page for the same users. It would be less likely to break for all users as well.
          • Better layout and design would eliminate the problem for lower-end clients and turn-around time.

            Please explain this. It's just stated, but i can't see it being a true statement. Please humor me provide some reasoning behind such a statement.

            Removing ECMAScript-based validation would lighten the page for the same users.

            By an amount that is idiotically negligable, especially in comparison to a server round trip.

            It would be less likely to break for all users as well.

            Superficially true. Well wri
            • A site with 10k of excess html (font tags and the like) and 5-15k of extra ECMA code tends to slow down lower end modems. So lightening the page by removing the above is step one.

              If you can't rely on the javascript working 100% of the time, then why write it? The graceful degradation is then replaced with outright elimination, and you don't get caught with your pants down when some new (broken) browser hits the block and mucks up your code yet again.

              Perhaps there is a misunderstanding about what I conside

              • and yet you can't depend on css working 100% of the time, so why use that?

                why not just write plain text ascii pages, that way nothing can break?

                almost every comment here specifically supports server side validation, yet you're saying "you suck, you're using ECMA in one form or another"... and you can write a reasonably complex validation script in less than 5k that can help people keep from being irritated because they EXPECT the form to have some kind of validation before it gets submitted..
      • Next, you should never rely on JavaScript to do your form validation. That's the most stupid, absurd thing I've ever heard. Leaving input validation in the hands of the client is to trust the user to not attempt to screw up your input. For forms to the useful, they have to be submitted to some kind of server-side logic. That is where the form validation should take place because then the user cannot side-step your input validation.

        It's bad to rely on JavaScript for form validation but it can be a good ide

      • "Next, you should never rely on JavaScript to do your form validation."

        The key word here is 'rely'. It's perfectly reasonable to allow the page to do simple first-pass checking of the content to avoid simple errors, like blank or incorrectly formatted data. You just need to ensure that (1) you re-validate at the server, (2) the form still submits if you don't have JS enabled (ie put validation code in the onSubmit event).
      • by mr3038 ( 121693 ) on Friday January 16, 2004 @10:23AM (#7997946)

        Its so simple, it works without JavaScript, loads faster, cross-browser compatible, and if the user is running a non-graphical browser, it's still accessible. Here's a quick example (where somepic.png contains both roll over states, one at (0, 0) and the other at (0, 20):

        a.Foo {
        display: block;
        width: 100;
        height: 20;
        background: url("somepic.png") top left no-repeat;
        }

        If you start throwing out examples, it would be nice to check that those work. You've a mistake there as "width:100;" or "height:20;" mean nothing. You have to define the unit unless the value you're trying to set is zero. Yep, they work in MSIE, but when did that browser knew anything about the standards? The correct format is width: 100px and height: 20px .

        After saying that, yes, for simple roll-overs [meyerweb.com] and cascading menus [meyerweb.com], the CSS is much better choice than javascript. Javascript should be used when the functionality required is much more complex [michaelbystrom.com].

        • I just jumped over to that cascading menus link and was amazed by the beauty and simplicity of it. I then cried a little when I realized that if I used this instead of javascript, 75% of my users would never see it. Damn IE.
        • Yes, you are correct that I fucked that up. I was in a rush. Awesome site btw, I love the design and the code. Little by little, well-built as well as well-designed sites are popping up. A couple years ago, you saw none of that.

      • Next, you should never rely on JavaScript to do your form validation

        You should never rely on it, but you should always have it (if supported by the browser). Web pages that use only round trips for validation are horrible and often incomprehensible. It's just plain bad interface, and the alternative is simple, easy, and produces a far better result.

        User clicks submit. You alert "You need to enter the donation amount" and set the focus to the appropriate field.

        If you think it would be better to let th
      • You shouldn't RELY on clients to validate, of course. But they should still do it.

        It's convenient for the user (quicker response), keeps the load off the server (which will probably only receive the final valid data, still checks it though) and even saves a little bandwidth. Everyone wins!

      • First of all i never said "Rely" on anything, However there are/may be circumstances whereby you might want to do a quick check on form content before subitting it to the server. You almost certainly will perform more robust checks when your form data gets back to the server. I would never advocate "Relying" on client side validation, that , is sheer idiocy. Im slighty pissed at the fact that you are insinuating that my work is a disaster.

        As for the CSS example you are suggesting. I have one thing to say .
      • Please change professions ASAP or read Designing With Web Standards [zeldman.com]
        Interresting read, but is he color blind?
  • Don't bother (Score:4, Insightful)

    by craigmarshall ( 679127 ) on Friday January 16, 2004 @09:15AM (#7997384)
    Javascript and DHTML are the worst technologies I know of.

    Stick with HTML/XHTML and CSS. You have PHP, what more could you possibly want? It's better to create web content that is accessible by everyone, than to produce fancy schmancy stuff that only a few people can access, and even fewer will appreciate. I hate Javascript and all other "dynamic" happenings in my browser. Focus on your content.

    Craig
    • Re:Don't bother (Score:5, Insightful)

      by Jerk City Troll ( 661616 ) on Friday January 16, 2004 @09:36AM (#7997532) Homepage

      I second this.

      There is no better way to create a more useless website to more people. You might as well just close your site now since you're limiting it to as few people as possible.

      If you're even thinking about DHTML, you probably aren't up to par with the latest web technologies that are designed to be more accessible and progressive. Please stop what you are doing and read Designing With Web Standards [zeldman.com] before you even think about building a website.

      Chances are, there is no need for any JavaScript on your website. It only adds needless complexity and helps things break. Again, as the parent poster write, use XHTML and CSS.

      • How about this Othello [demon.co.uk] game or this game of noughts and crosses. [demon.co.uk]
      • Re:Don't bother (Score:5, Insightful)

        by elemental23 ( 322479 ) on Friday January 16, 2004 @03:35PM (#8001709) Homepage Journal
        If you're even thinking about DHTML, you probably aren't up to par with the latest web technologies that are designed to be more accessible and progressive. Please stop what you are doing and read Designing With Web Standards [zeldman.com] before you even think about building a website.

        DHTML (really just the combination of HTML, CSS, ECMAScript, and DOM) is the "latest web technology". I'm not sure what you mean by "progressive" in this context, but well-written DHTML can be just as accessible as as well-written vanilla HTML. Please note my use of the words "well-written"; crappy code is crappy code, no matter what technologies you're using. The key is to make sure things degrade gracefully, so that your content or application is still usable in older or non-standard compliant browsers.

        Also note that Jeffrey Zeldman, the author of the book you recommend, uses JavaScript on his own web sites, including the very page you link to.

      • >>Chances are, there is no need for any JavaScript on your website.

        I try to use as much CSS and as little JavaScript in my sites as possible. However, chances are you will NEED to use Javascript on your site if you are doing anything more than basic CSS, if only to work around the abysmal CSS support in IE.

    • Stick with HTML/XHTML and CSS. You have PHP, what more could you possibly want? It's better to create web content that is accessible by everyone, than to produce fancy schmancy stuff that only a few people can access, and even fewer will appreciate. I hate Javascript and all other "dynamic" happenings in my browser. Focus on your content.

      I agree that using JavaScript to make a site more "fancy" is a waste of time and can lead to serious problems, but if you are writing a complex web application, JavaScrip

    • web content is the key phrase in your rebuttal. I use javascript constantly to manipulate my HTML documents, in service of an application. Not all of us are creating tributes to our favorite band or what have you. Sometimes pure HTML is a little too limited to make a functional UI.

      So far as the variuos problems with the web app paradigm, that's another topic entirely...
    • I once believed that Javascript was a toy language that was not worth the time. And once upon a time that was true. But times have changed. Today, Javascript is a suprisingly useful language.

      My area of expertise is telework, or remotely hosted applications. I've been writing PHP/SQL databases for years, and the end result always feels like a web page, not a program. In order to make an web based application "feel" like an application, Javascript is the thing.

      Take, for instance, Game Lib [javascript-games.org], a ja

  • ... there still is hope. Venkman won't run in IE, but you can get something like Venkman:

    To debug Javascript in Internet Explorer with more than just a few alert() statements, you need to install the MS Script debugger. It has two versions, one for NT/2000/XP and one for 9x/ME. There is even a KB entry describing how to find the Debugger in the jungle of microsoft.com: KBID 268445 [microsoft.com].

    Just my 2 cents.

    Tux2000

    • by Anonymous Coward
      If you have Visual Studio installed, you can use the fantastic debugging facilities that are a part of the package. If a js error occurs, a dialog box opens that says "do you wish to debug? y/n", say yes, and it opens in vstudio. You can get access to all the in state objects and their values from that point on.
      • My god, how I wish you could turn this off. Nothing is worse than browsing the web and having the debug message pop up a thousand times on somebody's poorly designed website. Yea, like I really want to debug their code. I know you can turn off script debugging in IE, but if you have Visual Studio, it must override that setting since it always changes back when you close the browser or restart the computer.
  • i've been doing the javascript work for years now. without a debugger it's been the most frustrating thing possible. also, since much of the work I do also involves back-end scripting in PHP, it becomes difficult tracking down the line of offending javascript since the line numbers in my editor don't match up with what's rendered in the browser (yes, i know, i could view script, but this just slows the process down)

    the best way i found is to use the alert() javascript function for variable inspection.

    on t
    • alert() *is* pretty handy for JS debugging, but these bookmarklets [squarefree.com] make it even more...um... handier.
    • There are lots of DHTML debuggers out there. Of course alert() is always handy, but having an actual debugger available really helps out.

      Visual Studio came with Visual InterDev, which does a passable job with debugging. Even with its flaws, it has saved me a lot of time over the years.

      Nobody needs a true debugger. Heck, nobody needs CVS. Nobody really needs profiling. Nobody needs a relational database.

      I think, though, that the best programmers will take the time to "sharpen the saw" and become profi
    • regarding

      the line numbers in my editor don't match up with what's rendered in the browser

      you can setup a good editor to help you to track all those errors. For instance (my setup):

      [HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Default HTML Editor\shell\edit\command]
      @="D:\\wbin\\vim\\vim62\\gvim.exe %1"
  • While it is mildly interesting to watch this food fight over proper approaches, languages to use etc. the discussion here appears to miss the point.

    Web programming lacks decent debugging tools.

    In my experience, we had browser hosted software, but it was targetted toward an intranet so we could specify the software that needed to be installed on both the clients and the servers. As the product became more complex and more developers were brought on, debugging became a nightmare.

    Although less technical min
    • I couldn't agree more
    • Sorry to break this to you, but there is a good web debugger. ASP.NET has a great debugging tool (Visual Studio .NET). There are probably others too. Of course, they only debug the server-side stuff, but all is not lost.

      I can write forms in .NET with JavaScript validation, without every writing a line of JavaScript code. This is because of specialized web controls that contain pre-debugged JavaScript, customized for the particular browser agent. Anyone can create these controls - I myself have not tho
      • At least 75% of the scripts I find at all the popular Javascript sights are ridiculously heavy for what they do - they also tend to be enormously slow (check out the DHTML menus at mta.info for an example). They rarely degrade gracefully, instead spending hundreds of lines of browser detection and browser specific behavior. Stock scripts like the kind you're advocating have probably cause me more pain in my web programming career than anything else.
  • Well... (Score:5, Informative)

    by JMZero ( 449047 ) on Friday January 16, 2004 @10:22AM (#7997931) Homepage
    Since you didn't mention it, everyone should at least let you know it exists: MS Visual Interdev has a script debugger.

    It isn't a magically good debugger (like some MS debuggers really are) but it works OK. It also benefits from integration with IE (ie, when Explorer encounters a script error, it can sometimes jump right to the debugger).

    It also does the IntelliSense thing (to an extent) allowing you to reference styles and objects without remembering their (often silly) names.
    • I can't be the only web developer who tends to have more than one window open at once, can I?

      When you open the debugger, you're in trouble. The second you close it, all other IE windows close. _Very_ annoying and means it gets turned off on all developer boxes here.

      (Hmm, must play more with Venkman and the DOM inspector to get more ammo for Moz with colleagues :-)
      • ...and the best solution I've found is to let it keep running until you're ready to have it "help out" by "crashing closed every Explorer window it can find".

        It's got some other wierd things going on and has some trouble debugging some stuff, but it's still useful enough that I keep it around.

        I suppose its usefulness would correlate pretty well with the size of the largest script you run. For most people creating public-oriented web pages, the largest script they write is going to be pretty small - and a
        • I don't know how you are set up, but in my experience IE will run in different processes if you launch it from a shortcut/launcher instead of using "New Window." I don't know if this is relevant to you or not, but it saved me a lot of headaches when I would crash browser windows.
      • all you have to do is tell IE to run in its own process (it's in the advanced options tab).

        'detach for process' is supported in the VS.NET (7 & 2003) debuggers.


      • That's easily avoided. Before you close the debugger, go to the Debug menu and select "Detach All".

        Detaching the debugger from a process leaves the process running. Stopping the debugger generally stops the process it's attached to. That's why when you close the debugger window, it asks if you want to stop debugging. Why it doesn't give you the option right there to detach all and then close is a mystery to me, since that's almost always what I want.

      • This use to drive me insane also. To get around it, select "Detach from process" from the debug menu before closing the debugger.

        Incidently, it's not ALL IE windows, just the ones that share the same root process (created via the "New Window..." menu or by opening links in a new menu).

      • Under the Debug menu (I think), is an option "Detach all processes", which lets you close the debugger and not kill IE.
    • Yeah I've used this. It's pretty good, though a bit flakey. You can even seamlessly debug into applets with Visual J++ (don't ask).

      But pretty good, nonetheless. Can attach to any IE process (think: Outlook)

  • I've spent several years writing various bits of functionality in JavaScript for clients. It is the worst platform to code for I've seen in some time.

    I've tried some of the debuggers, and found them to not be very useful at all.

    Sadly, you can't beat 'doing it the old way' using either alerts (useful as they're blocking) or setting up a debug layer (div) to output your debug content to.

    It sounds more like you're looking for a reference than anything else. I'd highly recommend the DHTML Definitive Ref [oreilly.com]

    • Re:DHTML Programming (Score:3, Informative)

      by swdunlop ( 103066 )
      And anything on the Mac is just a nightmare.

      Nope. Firebird's a little sluggish, but quite stable. Safari, which is packaged in these days, is nimble and does well on standards compliance and compatibility with old IE goofs for bad programmers.

      Biggest problem Mac users have these days are websites that try to outguess the client by header-sniffing.
    • For those of you that suggested just using XHTML and CSS.. that tends not to be an option in the real world. You would be amazed at how many Companies use version 4 browsers. And anything on the Mac is just a nightmare.

      Yes, I would be surprised. Do you have any statistics to back this up? And as for bad browsers on the Mac, what the fuck are you talking about? IE5, Safari, OmniWeb, and Mozilla (and derivatives) are all on the Mac and are all very standards compliant. OS X supports more browsers than a

      • OS X may support more browsers than any other platform, but how many average Mac users are going to hunt them down? Also, considering how popular the Apple/Mac duo is in education, and how many school districts--at least here in the midwest--are having funding problems and would hire the cheapest, inexperienced system administrators they could find, most Mac users are going to be on whatever is installed by default. So, if the default browser is standards compliant and capable, they're good to go. Otherw
        • you hit on a point that is more true than you think... School Districts here in the midwest have been hit hard over the last 5 years, and most have moved to WinTEL platforms for their computers... even 7 years ago when I graduated high school, there wasn't a mac in the building, and when I came to college, I found most of my fellow classmates had the same type of environment.

          Any more, the schools that can afford the macs are doing so because they have a sys admin that wants macs around, and usually they're
  • Dive into Mozilla (Score:2, Informative)

    by akweboa164 ( 629425 )
    I would recommend diving into the world of Mozilla. They offer a couple of awesome tools for Javascript and DOM debugging. Check out the following: Venkman Javascript Debugger [hacksrus.com] DOM Inspector [mozilla.org] Mozilla Firebird [mozilla.org] Specifically with Firebird, after you have it installed, go check out some of the available extensions at texurizer.net/firebird/extensions [texturizer.net] and download some of the cool extensions like the 'Web Developers Toolbar'. These pieces of software have proved invaluable to my productivity! I have used the
  • Web Developper Extension.
  • Go to Debug menu, click Show DOM tree.

    I assume other browsers have equivalents.
  • .. mozilla .. I am no different. then after you have developed and got it working in mozilla, start praying that it will work in IE.

    Here is what I have had problems with.

    DIV -> they lay them out close but when you get into needing pixel precision, I have had problems. Try laying out 2 div's next to each other and adding borders 1px wide and use absolute layout. Set widths and heights and then view in both. arg!

    IE has a bug when opening new windows. Session is gone, and so are your cookies. You ha

  • I tend to like things in tables with a good table browser and have a relational language to query them. I wish the DOM model was turned into a relational equivalent. It would require a lite-duty relational engine and perhaps "dynamic" columns rather than the pre-declared staticly-typed kinds often found these days. IMO it is easier to grok and query (study) information if it follows relational normalization rules. Wishful thinking? Perhaps. Non-relational structures have generally proven difficult to query
  • by swelling ( 322179 ) on Saturday January 17, 2004 @09:54AM (#8007034)
    One of the things that saved my sanity when doing a DHTML UI was creating a log window that I could write messages, the contents of JS variables, DOM objects, etc. to. It isn't as good as a real debugger, but it helped out quite a bit. I created a JS class that supported two methods:

    log = new Log();
    log.log("blah");
    log.dump(someObject);

    The first method just prints out the specified message, the second recursively prints all of the attributes an object, since in JS they are really just hashes that you can traverse automatically with a for in in x loop. At least in IE, this let me inspect form elements, etc. as if they were native JS things. The log class could technically be a singleton, but since each instance writes to the same window, it really doesn't matter. I just instantiate a new Log object at the top of each document, and can then enable/disable it at will by typing a javascript:log.enable() command in the address bar.


    function Log() {
    }

    Log.prototype.enabled = false;

    Log.prototype.enable = function() {
    this.enabled = true;
    this.logWindow = window.open("", "Log", "width=80,height=25,resizable,scrollbars=yes");
    this.logWindow.document.open("text/plain");
    this.logWindow.blur();
    }

    Log.prototype.disable = function() {
    this.enabled = false;
    this.logWindow.close();
    }

    Log.prototype.log = function(msg) {
    if (this.enabled) {
    this.logWindow.document.writeln(msg);
    }
    }

    Log.prototype.dump = function() {
    if (this.enabled) { // etc
    }
    }



    This is detailed in the O'Reilly Rhino Javascript book, which is an excellent resource for JS programming and DHTML.
  • When I was doing this kind of stuff way back when, I wrote my own Javascript thingy.

    It enumerates all the javascript objects it can find by using a call like "for i in x". I eventually got it opening in the search pane with a treeview that allows you to examine every value of every field you can find starting with window.opener.

    Not sure if it will work in Mozilla, and it does need to be loaded from the same site.

    Code available on request.

  • The script debugger was already mentioned. but If you go into the IE 5.x downloads section and get the Microsoft Web Developer Accessories [microsoft.com], it gives you some handy utilities. I know it says 5.x, but I've used these just fine in 6.xx. The "DOM tree" has a few issues, but can be handy for tracking down how to reference an object. View Partial Source, I find, saves me a ton of time, particularly when I am checking the generated HTML from a mixture of HTML/JSP code. I just highlight the HTML item I want to see

"If value corrupts then absolute value corrupts absolutely."

Working...