Additional Blogs by Members
cancel
Showing results for 
Search instead for 
Did you mean: 
eddy_declercq
Active Contributor
0 Kudos

So, you are convinced that writing cross browser code is the only way to make web sites and realize that not only do your users benefits but that you as a developer do too! The fact is that now you only need to maintain one standard set of code that'll run anywhere. Hey, didn't they say that about some other language before? Didn't its name start with a J and wasn't it somehow associated with some kind of beverage? Wasn't it just a little bit complicated and not so “write once run anywhere” due to the many proprietary libraries? Will that be the case with cross browser code too? Not if you take a few rules of thumb into account. Here's a small overview of references and tools that'll guide you through a smooth(er) coding process.

HTML
Every site is built upon HTML; even full Flash based sites like my personal one. That means that HTML is already one of the most crucial factors in cross browser sites. THE source for this is the World Wide Web Consortium (W3C) guidelines site. The Consortium's task/aim is to develop standards, which result in recommendations. This has its drawbacks though. First, as with politics, it takes a while before one reaches a consensus about things which can then be translated into a standard. That means that browser evolution isn't in sync with these recommendations. It wasn't a problem over the last couple of years, but with the revival of browser diversity, it's getting to be a problem again. Secondly, these are only recommendations. No browser developer is obliged to follow them. There are even hidden catches in browsers that claim to follow the standards. Thirdly, these specifications aren't novels and these tomes aren't that easy (to read). Have e.g. a look at the HTML 4.01 Specification.
Therefore, I would suggest a better source that'll give you the same result. It may seem a bit silly to the advanced HTML coder, but W3 Schools is a very good reference. Experienced coders can test their skills and get certified too.
Once you've digested the above and started coding HTML, you might wonder whether you're on the right track. There are a couple of tools to verify this. The first thing to do is to tidy up your HTML. This can best be done via the W3C HTML Tidy tool. The maintenance of this tool has now been taken over by volunteers and can be downloaded at Sourceforge, but you can still find some guidelines at W3C Tidy page itself. If you want to test things out in your browser like Firefox, there is an extension available to do the same. It is actually an HTML validator that also corrects the errors, that is if it understands the error that was made. If you want the most rigid rules to be applied you can always us the very strict W3 HTML validator.
There are plenty of other (commercial) tools or editors that will achieve the same result. Let me pick Dreamweaver as an example. First, the auto completion within Dreamweaver keeps you on the right track. However, if you do ignore it, you don't need to despair. The tidying up can be done via Commands->Apply Source Formatting, Commands->Clean Up HTML and Commands->Clean Up Word HTML. The latter is very handy for the SDN contributors among us who write the web log in Word and then want to copy and paste the text into SDN.

Before:

After:


Btw, there is always the Dreamweaver Dreaming of a perfect SDN web log editor made nearly a year ago.
After the clean up, the HTML validation can be done via File->Check Page->Validate Markup or use Shift-F6 directly. You can even choose the type of browser to validate but I wouldn't recommend it since you wouldn't have cross browser code as a result.

JavaScript
Once you've made the perfect HTML code you want your application to do more and include some interactivity in your pages. You can do this on the client with some JavaScript. Of course, now that you've put in so much effort to achieve cross browser HTML code, you want the JavaScript to run on all browsers. I'm going to have to disillusion you already. This is for the simple fact that JavaScript is not a W3C standard. There is something called ECMA 262, and there is no validator as such for it.  ECMAscript is also the base for ActionScript with Macromedia Flash.
Great, there goes my quest for cross browser code. There are some straws to grasp at though. First, there is the aforementioned W3schools, which is also available for JavaScript and the DevGuru reference for JavaScript. Btw, there is also one for HTML. Secondly, there are editors like ScrypTik that can help you out.


If you don't want to spend time in brewing your own JavaScript code, you might take a look at sites like Dynamic Drive and download ready-made scripts that'll do whatever you want. After all, you don't want to reinvent the wheel.

DOM and DHTML
Even if the JavaScript is syntactically correct, you might still get into trouble when using DOM related functions. To insure correct DOM references you will need to look at the specification for DOM at W3C. Yes, it's getting boring. W3C is THE source for everything. That's just the way it is. You will see that one talks about DOM, DOM2 and even DOM3.
For the layman, DOM stands for the Document Object Model, which is the interface that enables you to change content, structure and style of a document. Since it's closely related to HTML, most vendors refer to it as Dynamic HTML a.k.a. DHTML. As said, there are different versions of DOM and you may wonder which one to choose. Well, I won't tell you. It's rather complicated and it would be a rather lengthy and out of scope web log if I needed to elaborate on this. There are far better sources for that.

W3 Schools on DOM (of course)

W3 Schools on DHTML

Dr Dobbs Journal

Quirksmode

Write once

I must warn you that some of them are a bit outdated though, but they give a good start anyway. Therefore, I still find these previous Phantom of the Opera mentioned sites the best:

http://www.cross-browser.com/

http://www.htmlcenter.com/tutorials/tutorials.cfm/121/dhtml/http://www.wdvl.com/Authoring/DHTML/CB/.

I'm going to finish with an ugly duckling, meaning “The Web Standards Project” ( WASP). If it doesn't ring any bells, these are the guys from the much-feared Acid2 test I wrote about in an earlier article.
All this might seem a bit confusing and hard to learn. I won't disagree with you. On top of that, there isn't a real validator or editor to rely on. There is pre built DHTML available at the above-mentioned Dynamic Drive and editors like CoffeeCup.

CSS
Closely connected with the DOM are the Cascading Style Sheets. In contrast with DOM, you're less on you own when you want to code these CSS. As with the others, I would refer you first to W3C. You will see that there is something like CSS1, CSS 2.1 and CSS 3 , which is currently in development. It doesn't stop with those three though. One also has CSS Mobile Profile 1.0 for PDA and mobile phones, CSS Print Profile for low cost printers, CSS TV Profile 1.0 for TVs. If you can't see the wood for the trees, there is an excellent beginner's guide by Emil Stenström, W3 schools and of course the ultimate source by THE guru Eric Meyer and his books. Some of you might remember him from the S5 project I discussed in a S5 GE PPT or S5 LE PPT? last year.
Despite the diversity in CSS levels, there is also good news. Some excellent CSS editors like Stylemaster can make your job a little, or even a lot, more bearable . This editor does have features such as code completion and visualisation of the produced style. On top of that, it'll make sure that you write cross browser CSS or browser specific code.

If you want to make sure that everything is compliant, you can validate it with W3C CSS validator.

Conclusion
If your heart has sunk into your boots after reading all this, and think that the differences will prevent you from writing good cross browser, I can assure there is no need to be depressed. It is just a matter of picking the right tools to do the hard work for you. I've mentioned quite a few of them above, but it's up to you to pick the tool, or tools, that suit your needs the best. However, the most interesting tools are the browsers themselves. Personally, I have three computers (Windows, Linux and Mac) and a PDA, each with the most common browsers installed on them at my disposal. All this for the benefit of testing. The latter is, as with all code, whatever the purpose or language, the major keyword to success. If you don't have the resources, or don't feel the need to have the same kind of test battery as me, you can always rely on tools like this MultiOS Browser Test site. It gives you info on, and the possibility to test, your browser, JavaScript, graphics formats, CSS, DOM, WAI, XML, etc.
With all this baggage, you don't have any excuse for not developing cross browser site. It is just a matter of unpacking.