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.
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.
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.
DOM and DHTML
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
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:
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.
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.
With all this baggage, you don’t have any excuse for not developing cross browser site. It is just a matter of unpacking.