A Practical Start to Web Standards
It’s been expressed to me in a number of ways that making the switch to web standards is a very difficult process, and difficult for many reasons. Let me outline a few of the views I have picked up on.
Problems
CSS can be strangely complicated at first glance (it’s a very different animal than HTML, JavaScript, etc.). And having to validate your XHTML? It’s like debugging a C script, isn’t it? I thought HTML was a markup language, not a programming language. The world of standards can be very threatening to the newcomer and the seasoned developer alike.
Convincing superiors/clients/coworkers to make the switch with you can be equally difficult, especially in an established environment. It’s the old “If it aint broke, don’t fix it” mentality, and while often trustworthy, it’s an all too common, and frankly dangerous, mindset.
Lastly, and in my opinion the only valid argument, learning everything to do with web standards takes time —- time I don’t have. Because I am insane, I actually enjoy spending a full workday creating websites, followed by a fun-filled evening of —- you guessed it —- creating websites. But every web professional can’t be expected to use their valuable free time to learn the latest-and-greatest methods, especially one whose real enjoyment of web design comes from the paycheck at the end of the week. (And there is nothing wrong with that motivation.) The trouble is that most businesses don’t have the capital or man-power to spend days on end tinkering with box-model hacks, image replacement techniques, and the like. And clients don’t have the patience (and rightfully so) to wait around for their hired professional to take time out from their job just to learn how to do it ‘right.’ It’s a vicious circle.
Suggestions
So, now that I’ve presented a few obstacles in the road to standardization, let me blaze a new trail around them (or at least leave some noticeable footprints).
When staring new languages/methods in the face, it’s always a good idea to step back and evaluate the situation. Make sure you understand why you agree with web standards. Specifically, it’s good to remember that ‘web standards’ is not specifically about validating XHTML or CSS or JavaScript or any other big buzz-word. What it is about is doing things in a logical, organized method which will (eventually, those new to CSS etc. will have to trust me) increase productivity, usability, and accessibility of your site.
So now that you’ve convinced yourself that web standards are the way to go, how do you convince others? I have to take myself back to the days of early programming. Good old BASIC. In playing around on my own, I began to develop the habit of using GOTO commands. Upon taking formal (as formal as you can get for high school) instruction, I was told that the use of GOTO commands was a very dirty habit, and one I should avoid in the future. My first reaction was to take offense. “How can you say that my work is wrong if it gets the job done? Don’t judge my methods!” Well, as it turns out, my GOTO commands got the job done, they just did it in a horribly messy way. It took some time, and some education on my part as to the ‘correct’ way to do things, but eventually I realized what my instructor meant. I could fully understand the benefits once I was able to utilize them. But it took time, and a bruised ego.
Changing peoples methodology is never easy. They will most likely take offense that you are ‘correcting them’ or ‘telling them they are wrong.’ And it very well could be that you are. If you run up against this type of resistance, my advice is to start off small. Baby steps. Start by introducing CSS as a way to manipulate fonts in your document. Maybe start to cut down on the nested tables. Eventually people will catch on, and when they do, progress has been made.
Similarly, if you just can’t find the time to learn, or your employer isn’t keen on the ‘Research Time,’ suggest you start off by redesigning the company website with web standards. If that’s too big (or too sensitive) of a job, than there is probably a smaller intranet site that could use a little remodel. Find things to do for your own company, things that can be picked-up and dropped at any given time. It’s usually the case that client work comes first, company work picks up the slack.
Conclusion
My conclusion for this article is simple. Start small. Don’t expect to make a Zen Garden entry overnight. Even if you can eliminate one <font> tag or layout-containing <table> from your page, you’re on your way.