Seeking Good DHTML Debuggers?

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?"

Comments

Venkman

[TulioSerpio]

Mozilla and Firebird come whith a Javascript debugger, and it works.

Re:Venkman

[DetrimentalFiend]

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

[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

[Anonymous Coward]

I've had strange issues where I pull up my buggy code in the Mozilla Debugger, and instead of seeing my errors, I see about 100 errors coming from XUL files.

Are these actual bugs in Mozilla, or is my code somehow screwing up the XUL?

Re:Venkman

[AKAImBatman]

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.

Re:Venkman

[Anonymous Coward]

99% of the JS/DOM you write for Mozilla will run unmodified in IE.

(The only big exception is event code, and that seems kinda fubar'd on Mozilla anyway.)

Note the reverse is not true -- IE is generally a lot less strict than Mozilla in terms of both js parsing and how you use the DOM. Also, IE supports a bunch of proprietary extensions, including crazy legacy stuff like "window.elementName" and so on.

Re:Venkman

[Goyuix]

For IE, I have found the Microsoft Web Developer Accessories 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 deal with it properly. No reason there couldn't be one good tool, just I have yet to see any I like as much as the few I use regularly.

Re:Venkman

[Anonymous Coward]

99% of the JS/DOM you write for Mozilla will run unmodified in IE.

Not quite true. Microsoft's JScript is nowhere near 99% with the Javascript engine in Mozilla. There are some significant differences in the behaviour of Arrays for example, especially when you are creating objects based on Arrays. (ie, using foo.prototype = Array;)

Re:Venkman

[Bitsy Boffin]

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

[Anonymous Coward]

yeah it's really true :)


stars x

How about Mozilla DOMI

[alanjstr]

The Mozilla Document Object Model Inspector is very useful. It comes with Mozilla and Firebird.

http://www.mozilla.org/projects/inspector/

Moz has got you covered!

[seanmeister]

In addition to the Venkman JS debugger mentioned in a previous comment, Mozilla and Mozilla Firebird also include an excellent DOM inspector - very handy for page tweaking, "DHTML" or not.

You already have the tools

[polyp2000]

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 the offending browser (after an error has occurred) and / or stepping through the code and evalutating variables using the javascript command

alert(insert_problem_variable);

has been able to help me debug frustrating problems most every time. I really dont think you need to fork out hundreds of dollars for a debugger when you just need to use your nonce and a copy of the best javascript book ever written

Re:You already have the tools

[Anonymous Coward]

I have been making web sites since for 9 years... and whilst your /*alert()*/ tip is helpful, your post is not insightful.

Technologies like JavaScript + CSS (=DHTML) are STANDARDS - they are created to use in web browsers. I use them wherever I need to, and code for MSIE and NS6+ (with a focis on the latest Mozilla release).

Re:You already have the tools

[Jerk City Troll]

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 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

Re:You already have the tools

[edwdig]

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.

Re:You already have the tools

[Viol8]

"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...

Re:You already have the tools

[(trb001)]

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 the client, helps to decrease your server's load and shortens the overall time needed to input data by informing the client of errors before submitting. While not a problem on your LAN, clients over dialup can take seconds if not longer to submit a single form, let alone page after page of them. Knowing that a date has to be in a certain format or that 5 fields are required before submitting shortens their time considerably.

--trb

Re:You already have the tools

[gibi]

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 idea to do JavaScript AND server-side validation. It can be good for the user (mainly because you save one page load if the validation fails).

Re:You already have the tools

[mykdavies]

"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).

Re:You already have the tools

[LeftOfCentre]

VERY well said!

Re:You already have the tools

[lowmagnet]

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.

Re:You already have the tools

[mr3038]

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 and cascading menus, the CSS is much better choice than javascript. Javascript should be used when the functionality required is much more complex.

Re:You already have the tools

[lowmagnet]

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.

Re:You already have the tools

[Moeses]

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!

Re:You already have the tools

[TrevizeNet]

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.

Re:You already have the tools

[polyp2000]

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 ... Netscape 4.7! Again I agree that one should adhere to standards but in many situations it is simply better to design a website that doesnt use the technologies that so readlily screw up.

Before you go slagging someone of you should get off your high horse and stop jumping to conclusions.

The main crux of my post was to say not to use Javascript for anything too complex, if you have to use it at all.

Re:You already have the tools

[lscoughlin]

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

Re:You already have the tools

[lscoughlin]

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 written javascript degrades well though and won't impinge on usability.

Should the operation of your pages depend on javascript? No. But i'd rather have them depending on javascript then CSS unless i get to specifically target a browser.

-T

Re:You already have the tools

[lowmagnet]

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 where the business logic lives anyway.

Re:You already have the tools

[lowmagnet]

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 consider field validation. I consider field validation to be code tied to each individual form element to tell the user if they:

1. filled the field in (if required)
2. filled it in with the right type of data

While I agree that the first one would be a simple check, the second one is not so simple, I don't agree with meeting the second criteria on the client side. Every solution I've seen proposed to do this in ECMA code too closely fits the definition of 'kludge' to me. Call it a personal aesthetic.

Re:You already have the tools

[imr]

Please change professions ASAP or read Designing With Web Standards [zeldman.com]
Interresting read, but is he color blind?

Re:You already have the tools

[fean]

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..

Re:You already have the tools

[Anonymous Coward]

Read this again:
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.

If you don't agree whith that, it might be better for you to stop webdevelopment altogether.

Re:You already have the tools

[alienmole]

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 validation and other client-side logic, we wouldn't have been able to use a browser at all.

Don't bother

[craigmarshall]

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

[Jerk City Troll]

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 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.

Re:Don't bother

[splattertrousers]

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, JavaScript and other tricks can really improve the user experience.

The trick is to make sure that the site works without JavaScript enabled and to test the JavaScript on as many browsers as you can. Because that is time consuming and expensive, you need to make sure that adding a certain script is worth the expense.

It could be argued that complex applications shouldn't be web-based, and I'd generally agree with that, but sometimes it makes sense (and other times, it doesn't make sense but someone makes that decision and then pays you to implement it).

Re:Don't bother

[heinousjay]

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...

Re:Don't bother

[christodd]

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, a javascript library for writing games. These games are far more "cross-platform" than anything else out there. Or Javascript Windows, which simulates multiple browser windows in a single web page - even allowing form submission with reloading the document. And how about that DHTML debugger written in Javascript ? You can't do those things in PHP.

I find that the Javascript/PHP/SQL can be used to create cross-platform, remotely hosted applications. And until we, as the development community, start taking advantage of Javascript, it will continue to be buggy in all the browsers. Once we make it a standard part of the process, then the web browsers will make more of an effort to support it.

Re:Don't bother

[elemental23]

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 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.

Re:Don't bother

[Anonymous Coward]

"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."

Why do you assume that we are all creating web sites for a broad worldwide audience? Many of us write web sites for businesses and companies where we know who the users are and which browser they have. Often development time and cost is more important than being able to work with all other browsers. Therefore, in many cases it can make sense to use JavaScript. It depends on your goal.

Re:Don't bother

[hayds]

>>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.

If you are forced to use the MSIE ...

[Tux2000]

... 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.

Just my 2 cents.

Tux2000

Re:If you are forced to use the MSIE ...

[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.

Re:If you are forced to use the MSIE ...

[gcaseye6677]

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.

Re:If you are forced to use the MSIE ...

[Pfhreakaz0id]

hmmm, I turn off mine and it stays off until I turn it on. Not sure what your issue is. Maybe because I have both VS and Script Debugger installed. I dunno? I just check "disable script debugging." in tools ->> internet options.

alert() ... it's your best friend

[pdk]

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 the other hand, it's probably best to avoid javascript as much as possible, even for form validation. it's not worth the headache from a programmatic point of view.

Re:alert() ... it's your best friend

[seanmeister]

alert() *is* pretty handy for JS debugging, but these bookmarklets make it even more...um... handier.

Re:alert() ... it's your best friend

[r0.ini]

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"

Really? Try doing this in in XHTML & CSS.

[Viol8]

How about this Othello game or this game of noughts and crosses.

Re:Really? Try doing this in in XHTML & CSS.

[trg83]

And that is so important to the average company web page how? I thought the discussion was regarding professional web sites designed to convey a positive image for the client. Perhaps I inferred too much...

The answer appears to be no

[dfinney]

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 minds felt that the product should be a "pure web solution", we began implementing a number of server side COM objects in C++ because we COULD debug them. Explaining them to new developers on the project became easier, too.

Re:The answer appears to be no

[dyte]

I couldn't agree more

Re:The answer appears to be no

[Anonymous Coward]

> server side COM objects in C++

First of all, there's nothing about server-side COM that makes it an "unpure" web solution. Client-side ActiveX, yes.

(Although after having to deal with deployment issues with COM-based webapps, COM can go fuck itself in it's stupid ass. DotNet exists for a reason.)

Second, you seemed to have missed the point that this is about client javascript debugging, not server-side scripts.

Well...

[JMZero]

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.

Re:Well...

[LadyLucky]

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)

DHTML Programming

[DamnYouIAmALion]

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 Reference. It covers everything, along with good structural tips, like creating a platform independent DHTML API.

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.

Hope this helps.

Re:DHTML Programming

[swdunlop]

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.

Re:DHTML Programming

[Anonymous Coward]

informative!? pfft

no, it does not help (clueless moderators on crack again)

Re:DHTML Programming

[Anonymous Coward]

Yay. Post no. 8 million. Whoopee...

Re:DHTML Programming

[dedazo]

Hello!! you got the #8,000,000 post. That's quite an achievement. However, because you elected to go AC, I'm claiming this post.

8th millionth post!!

Have a nice day!

You need to qualify that...

[JMZero]

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 the submit happen, and return the page with an error at the top saying "Amount not entered - you must enter something in all the red fields!", you're silly. By the way, I've seen exactly that on a web page - apparently their hatred for employing available browser technology meant they couldn't even set the focus to the missing field.

This is just bizarre...

[JMZero]

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 proficient in using all these tools. If you're programming without a debugger, you're not working as efficiently as you could. And yet half the replies here suggest the poster is asking for something unreasonable or unavailable. Bizarre.

Dive into Mozilla

[akweboa164]

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 DOM Inspector Mozilla Firebird Specifically with Firebird, after you have it installed, go check out some of the available extensions at texurizer.net/firebird/extensions 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 them to debug javascript, XUL and everything in between. Good luck!

I use Firebird, Venkman debugger and the

[xutopia]

Web Developper Extension.

Critical problem

[GregWebb]

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

Re:Critical problem

[spongman]

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.

Re:Critical problem

[arkanes]

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).

Re:Critical problem

[CTho9305]

Under the Debug menu (I think), is an option "Detach all processes", which lets you close the debugger and not kill IE.

Indeed...

[JMZero]

...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 debugger is going to be something they pull out rarely. I end up writing some fairly long scripts at times, and I find it's often worth whatever hassles it presents.

In any case, I too might have to try out some of the alternatives listed in the comments.

Re:Indeed...

[Anonymous Coward]

Prior to Windows XP there is no support for a debugger to detach from a process without causes the process to be terminated. Since IE uses shared sessions all open IE Windows are closed when the parent process terminates.

Re:Indeed...

[trg83]

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.

Re:Indeed...

[Anonymous Coward]

That's not true, VS 2002 and VS 2003 both support unattaching from a process without terminating it on Win2k. I use it all the time when debugging.

Re:Indeed...

[2short]

Funny, I've been doing it since NT4.
I must be magic.

Re:The answer appears to be YES

[DukeyToo]

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 though, because I am not interested in doing the low-down technical details. I can buy something for less money than it will cost my employer to pay me to build it.

Even when not using ASP.NET, I have almost never written any JavaScript from scratch. Why do it, when I can spend a few minutes browsing and find a script that does what I want? So, my advice would be to take a step back and consider not re-inventing the wheel unless you have to. Or unless it is your job to manufacture wheels.

Not true. Care to share what you're smoking?

[Jerk City Troll]

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 any other platform.

By the way, you've clearly missed the whole point on standards compliant web development. If you build a web site with standards, its degredation (if necessary) will be graceful. For example, if I write pages using XHTML, everything from screen-readers to Lynx to Netscape 4 to the latest version of WhizbangBrowser will be able to use and navigate the content. That is most definitely not the case with other "solutions".

If we use DHTML and JavaScript on the other hand, everyone except those with WhizbangBrowser are locked out of the content. I think what you meant to say was: "For those of you that suggested just using DHTML and JavaScript.. 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 Windows is just a nightmare."

Please get a clue.

Re:Not true. Care to share what you're smoking?

[Anonymous Coward]

Jerk City Troll, you are so abrasive. There really are much better ways to make your point. It's so unpleasant to read anything you post.

Understated, DHTML is difficult. However, in my experience, if you adhere to XHTML and can get your code to work in Mac IE5 and Netscape 4.7 then it will work in %99.9 of the browsers out there (not %100 because I havn't tried them all).
People often slam Netscape 4.7, but truth be told it is an excellent yard stick to measure your code against. The reason why is because it fails on bad code instead of trying to compensate for it. It DOES support DHTML, but the the support is lacking. However, despite the lack of support you can still do many nice things with it. I have.
I'm also surprised that in a discussion of DHTML no one has linked to Quirksmode, which is extremely useful.

Safari

[addaon]

Go to Debug menu, click Show DOM tree.

I assume other browsers have equivalents.

Written in haste.

[Jerk City Troll]

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.

Re:Not true. Care to share what you're smoking?

[Jerk City Troll]

Jerk City Troll, you are so abrasive. There really are much better ways to make your point. It's so unpleasant to read anything you post.

This comes from years of pent-up frustration from working with people who don't understand why this stuff is important. What's worse is reading people making suggestions to learners that will no doubt perpetuate bad web development practices. It's often been a difficult up-hill battle where people refuse to even try the standards-compliant, structural-markup approach. Nevertheless, I've proven the virtues of standards-compliance time after time again.

Most recently, my company was slating a lot of time to make an alternate theme and printer-friendly pages for a web application. I convinced them to let me redo the site in XHTML and I was able to deliver any theme they wanted in less than half a day creating new stylesheets. With benefits like these, I just cringe at other approaches.

But yes, I need to learn to be less pissy. :) (Sorry to everyone who I've spit venom at today.)

Re:Not true. Care to share what you're smoking?

[trg83]

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. Otherwise, they're pretty much screwed.

Re:Not true. Care to share what you're smoking?

[Anonymous Coward]

Trying to debug anything on MacIE or Safari is a real pain in the ass. Neither will even bother to tell you when you have a syntax error -- the javascript will simply stop at some random point.

Despite what you say about standards compliance, the W3C DOM implementation is basically shit on both MacIE and it's replacement Safari. (Both do OK with CSS.) It's like Netscape 4 standards -- sure it's "supported", but it doesn't work.

> For those of you that suggested just using DHTML and JavaScript.. that tends not to be an option in the real world

The "real world", at least for vertical apps, is "rich interfaces" on Internet Explorer for Windows. Generally if you do it correctly, these apps will run just fine on Mozilla and sometimes on Safari. Nobody pays for simplistic XHTML that degrades gracefully.

most people seem to lean towards..

[josepha48]

.. 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 have to basically do a get for IE passing the session and any cookies or info you need. Arg IE sucks if you use new windows.

Mozilla does not deal with the object tag the same as IE especially if you are dealing with word documents. Mozilla needs a plugin IE embeds the control for you without the plugin.

Crossbrowser DHTML can be a real chore, but it depends on what you need to do.

Mozilla and Firebird come with the JavaScript Console, which shows you ALL the errors when the page loads or the script gets executed, I have not seen this in IE, not to this extent. This is basically ALL I use for my DHTML.

For more info on what is going on I use the http headers plugin for Mozilla / firebird to see what cookies are being sent and what is going on. Then I have to go and debug it to get it working in IE. Once you have it working in both IE and mozilla it usually works in Opera and Safari and Konqueror.

Re:most people seem to lean towards..

[Anonymous Coward]

they lay them out close but when you get into needing pixel precision, I have had problems.

When you start using pixel precision, I have problems. My eyes aren't very good and I browse with large fonts. If a site is relying on pixel sizes, it WILL be messed up when I look at it, and I WON'T be coming back.

This is why you should use structural markup: not because it's magically "easier" or "more compatible", but because it's more accessible. Fuck prettiness, I want to be able to read your content.

RDBMS style

[Tablizer]

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 over the years, and when they grow past a certain complexity it starts to show. They found this out in the 60's when early databases were trees, associative arrays, and pointers.

myEclipse & Tomcat5

[Anonymous Coward]

I code DHTML on a daily basis. I use the MS Script debugger(free). I also use myEclipse plugin for the Eclipse IDE. If you use Tomcat5 you can debug/animate JSP pages which is handy in many cases. Also as in a previous post alert() is your friend!

--freak

No problem

[2short]

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.

Re:Not true. Care to share what you're smoking?

[fean]

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 very experienced in handling macs

(p.s. I highly doubt OS X "supports the most browsers of any platform"... there are so many prototype browsers developed by educational institutions [2 created here last year alone], just because macs have two browsers that won't run on any other platform doesn't mean they have the most... windows has a lot of the same types of browsers!!!)

Re: Trust the Standard.

[E_elven]

>Technologies like JavaScript + CSS (=DHTML) are STANDARDS - they are created to use in web browsers. I use them wherever I need to, and code for MSIE and NS6+ (with a focis on the latest Mozilla release).

Interesting contradiction.

I say: do not find out what browser does what; find out what the respective standards say, and code according to that. Someone's browser will display it wrong, but that's mitigated by including the following disclaimer: "Your browser does not fully support the existing website standards, and you may suffer problems on other sites as well. You may continue to viewing the site, or you can download a standard browser here."

If more webdevs understood that, we wouldn't even have to have this discussion.

.

Re:The answer appears to be YES

[arkanes]

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.

Re:Not true. Care to share what you're smoking?

[arkanes]

The fact that you rant without listening to what other people are saying (see your previous rant against roll overs for an excellent example, because you jumped on a high horse without thinking the problem through) also rather detracts from you point.

Not to mention that XHTML isn't some magic potion that'll make your site work properly. CSS and stylesheets are great for that sort of thing, but the various cross browser issues force all sorts of hackery that reminds me a great deal of the stupid crap we did to work around bugs in table rendering in the 90s (@import to "hide" from old browsers? Bah). At the sites that oh-so-helpfully explain these tricks sound so proud, as they talk about the advantages of web standards.

Yes, I know that using tables for layout is evil. Of course, theres a variety of layouts that CSS is simply incapable of, and the cross-platfrom CSS you need to properly implement even some relatively simple layouts is far larger than the comparable table code, and it'll work (not even degrade to simple text, but actually WORK) on non-CSS compliant browsers, and it'll render faster (and often in a more user-friendly manner) than the CSS...

I use CSS alot for effects and styling. It's really handy for some layout stuff (like a static menu). It's makes a great addition to a table based layout, where you used to have to play games with single pixel cells and whatnot. But it's a nightmare for overall layout. Call me when CSS 3 is finalized and has at least 80% support in all major browsers.

Not really a debugger, but ...

[swelling]

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.

Re: Trust the Standard.

[Mr. Shiny And New]

If everybody coded according to the standards, there would be nothing on the internet worth seeing, since most browsers don't follow the standard. I like standards as much as the next guy, but software is a business, and people write websites to solve problems and satisfy customers/users. If your website is standards compliant, but not usable by your target market, your fanaticism costs you your customer.
Web developers can't just close their eyes and say "I will only follow standards!" To think so is naive.

Re: Trust the Standard.

[E_elven]

The inference was that if everyone wrote standards-compliant code, then the BROWSERS WOULD HAVE TO DISPLAY IT! Better sites and less buggy browsers. Geez.

Re: Trust the Standard.

[Mr. Shiny And New]

It's a bit of a catch-22, isn't it? If I write standards-compliant code, and no browsers support my standard, then my site is useless. If enough sites are useless, customers will complain that they can't reach the sites they want. But meanwhile, my site is useless and thus I don't get paid. So I write a site that works, even if it's not standards compliant, and then nobody complains, so browsers don't need to support the standard.

The key is that a standard is only as good as the implementations of it. Even if the NEXT version if IE or Moz or Konq is so great that it supports all standards you care about, there are still going to be so many people who are unable to use that next version of the browser. So they use an older one, that still works. So, if I care about those people, I have to support them. That's how things work; that's why computer systems get crufty. And that's why people use HTML tables for positioning, or javascript when they should use CSS (or vice-versa).

Re: Trust the Standard.

[E_elven]

If you cared about the people, you'd inconvenience them temporarily by using standards-compliant code only. Hacking to suit the browsers will inconvenience a significant group of people perpetually.

Don't get me wrong, I understand the socio-economical factors here; I'm just saying that long-term, this would be a better choice.

Simple, write your own .... err well for me anyway

[complete loony]

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.

A handy thing for IE

[Pfhreakaz0id]

The script debugger was already mentioned. but If you go into the IE 5.x downloads section and get the Microsoft Web Developer Accessories, 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 the source for and right-click and choose "view partial source".. No more searching through the HTML source to see if I set the property right or my JSP is hosed.

MOD PARENT UP

[sulli]

Eight millionth post. Informative or not, truly a historic slashdot moment.

Flashing Javascript

[Anonymous Coward]

Hi, I have at my site here a javascript for flashing the title "Inge's Homepage" in colors yellow and red. But, unfortunatelly, this script does not work. Can You please help me?