Part 1: Web programming, standards and JavaScript tips

Howdy, Dori. You started programming twenty-something years ago, tell us about the beginning.
Well, I started off banging two rocks together, and look where I am today! Actually, like a lot of other people on the Web, I started off programming in high school. Unlike a lot of other people on the Web, that was in 1977, before most of them were born.

I learned BASIC on a machine that looked like a typewriter, which was connected via an incredibly slow line to a mainframe several miles away. I found that programming came easily to me and when I realized that I could get paid good money for solving puzzles, a light went on and I said, "This is for me!"

Amazingly, everything I learned in 1977 still applies today: I recently reviewed RealBASIC for Macworld magazine and the patience that came from working with a slow connection comes in handy almost every time I try to look at a website.

How did you arrive where you are today as an expert on Web programming and design?
First off, I want to make it clear that I'm not an expert in design, but that's probably pretty clear to anyone who has visited any of my sites.

So far as web programming goes, I was mostly in the right place at the right time. I first got online in the early 1990s, as was normal for a computer geek. In the mid-'90s Java and JavaScript came along and they just looked really, really easy to someone who had been programming as long as I had. At that same point I was completely fed up with my dead-end mainframe programming job and was looking for something different, so I jumped ship in 1996 and taught myself rudimentary HTML, Java and JavaScript.

What I found was that what came so easily to me wasn't quite so easy to non-programmers, and I started teaching classes. I then realized that understanding concepts and being able to explain those same concepts to non-technical people are two very different beasts and that while lots of people can do the former, not so many can do the latter. The same light that went on in 1977, went on again in 1997 and I switched gears and changed over to primarily write and teach about web programming.

What is your role as a steering committee member of the Web Standards Organization?
My role has evolved over time. When the Web Standards Project (WaSP) first started up in 1998, my job was to remind people how much of an issue cross-browser compatibility was between JavaScript, JScript, and ECMAScript. Since then, for the most part, browser makers have figured it out and have started to release standards-compliant browsers.

Standards compliance on the Web is a three-legged stool, and if any one of those legs is missing, standards are pointless. Firstly, we needed standards-compliant browsers, and we're slowly starting to get those. Both IE and Netscape are darn close, and the other browser makers understand that it's a feature they need to include to be competitive (enough so that at least one browser company lies about how standards-compliant its product is just to appear viable.)

This is what the WaSP spent its first two years preaching about, and it's finally starting to have an effect. The two biggest issues now for the Web Standards Project are the other two legs of that stool: user browser upgrades and the creation of standards-compatible tools.

It doesn't make a difference for Web developers building sites if standards-compliant browsers exist if people aren't using them. Unfortunately, some of the older browsers out there (such as Netscape 4) are so bad that they crash when they hit pages that use advanced features of DHTML, even when those pages comply perfectly with standards. The only way to make standards safe for Web developers to use is to encourage users to upgrade to browsers that support the standards.

In this area, my role started as the instigator of this campaign, and I wrote the JavaScript code that can be added to pages to help check whether or not the browser supports the W3C DOM.

The third leg in the stool is the tools used to build websites. Many web page designers would like to support standards on their pages, but they use WYSIWYG tools that don't create standards-compliant code. To the best of my knowledge, it is not possible to create a standards-compliant site with any of the currently shipping WYSIWYG editors (or at least not without touching the code, which wrecks the entire point of using WYSIWYG editors.)

What this means is that it's time for the WaSP to do a little education, of both the toolmakers and the tool users, to show why standards-compliance is in everyone's best interest. We've been doing this quietly over the last few months, and both Macromedia and Adobe are at least listening, which is a start.

We interviewed your Web Standards head honcho, Jeffrey Zeldman. He listed websites for developers to use as a reference to help with standards compliance. What suggestions do you have for good reference sites?
The most important site of all for standards compliance help is, of course, the W3C's HTML Validator. If you're not sure yet if your code validates, or even what that means, using this site against your pages will help get you up to speed quickly.

For JavaScript, I find I get the best results by going straight to the browser makers for help. Microsoft offers the JScript site, and Netscape has DevEdge Online, a large documentation site. Another good resource is Introduction to Cross-Browser, Cross-Platform, Backwardly Compatible JavaScript and Dynamic HTML. With a name like that, how can you go wrong? And of course, there's my own JavaScript World.

Javascript enables Web page designers to include interactivity in their Web pages. What are some issues they should be aware of when using JavaScript?
The biggest one is insufficient testing!

There are a huge number of browsers out there and people have a habit of testing just their own setup and then assuming that their pages work everywhere. If you try your site on a larger number of browsers (think multiple platforms, multiple versions, and multiple vendors) you'll be stunned at how many errors your visitors are seeing.

The second biggest issue is assuming that your visitors have JavaScript. There are a number of reasons why someone might be visiting your site without JavaScript enabled (think about PDAs, for example) and making your site useful if and only if the user has JavaScript is a big mistake. JavaScript should enhance your site; it shouldn't be a requirement.

What frequent mistakes do you see on pages designed with JavaScript?
The most common mistake I see, again, is the way JavaScript is used on sites that assume that everyone has Internet Explorer for Windows. That's not the browser I use most frequently, and I get to see a truly amazing number of errors on sites that I'm sure work just fine on Internet Explorer for Windows.

The next most frequent mistakes I see are due to using JavaScript when it shouldn't be used, and not using JavaScript when it should be used. In the former case, I'm really tired of things flying around and following my cursor just because the site's developer can do these things. Yeah, they're okay on a home page, but not on anything that needs to be taken seriously.

And then there are the sites that aren't using JavaScript when they should be. I tried to buy something recently online, and I filled out all the forms, hit submit and waited and waited for it to verify my information. And finally, the response came back that it didn't like that I'd entered some spaces in my credit card number.

Now, there's no reason for the page to have to go to the server to find that problem. It could have been done completely on the client side, with a quick JavaScript field validation. It would have saved time, saved some frustration on my part and it would have taken some of the load off their server.

Continued...