Change is the in air in the web development community, you may not like it but it’s happening. If you have spent much time in any forum for designers and developers lately you have probably run into a “web standards debate” (or should that be flame war) or the “tables for layout versus CSS positioning debate”. The issues tend to be intertwined, confused and after dividing those with a strong opinion either way into two opposing camps, leave those just starting out and those who were happily unaware of these issues standing around wondering what on earth just happened.
So whose standards are these?
The “web standards” to which we refer, are standards set by the W3C in order to create an html specification that all html authors (thats you and me), browser manufacturers (Microsoft, Netscape, Opera etc.) and manufacturers of tools which write html (Macromedia, Adobe etc.) should follow. The various browser manufacturers have always added in their own special tags and functionality to the HTML specifications and this is not so much a problem. What is a problem is the different ways in which the browsers interpret the standard html tags that we all use to mark up documents.
As an example, imagine if Internet Explorer decided that the tag should be interpreted as being 12 carriage returns whilst all the other browsers interpreted it as 2!
The above is obviously an extreme and unlikely thing to happen, but smaller and similarly problematic differences are present in all of our current browsers. These differences were probably at their greatest with the version 4 browsers that many people are still using today, even though there are much improved versions available for free download.
Why is this a problem?
It’s a problem when browsers don’t stick to standard code for many reasons. Time is a major factor for most of us working as professional designers and developers. The time that it takes to hack around display bugs in each browser could be better spent improving our sites and our skills. In addition, many of the methods used to counteract browser bugs in the version 4 browsers make our sites totally inaccessible to those using alternative browsing devices to view our pages – braille readers and speaking browsers for example.
Are things getting better?
The good news is that they are, the most recent generation of browsers are much closer in their implementation of the W3C standards than ever before. If you code to the W3C standards much of that code will work in most cases, and in many of the cases where there are differences they are no big deal or a slightly different (and still standards compliant) tactic will fix the problem. Even if you do run into a true browser bug, the fact that your code validates will make it much easier to identify the bug and find a way of getting around it by searching the many resources now available to address browser issues.
Is there anything that can be done to encourage more compliance?
The fact that browsers have become more compliant means that browser manufacturers have been listening, but there is still plenty of room for improvement. The Web Standards Project should be your first stop for information on the campaign to get better standards compliance in our browsers and authoring environments. They have done amazing work in bringing the standards issue into the open and the site has pleny of resources to help developers bring their sites up to the standards. The more developers who start to code to standards the better, as it will show those who build our browsers and authoring tools that this is what the development community want.
So what about the tables v. CSS thing that everyone is shouting about?
Part of the W3C recommendation is that tables should not be used for layout but only for tabular data, tabular data is the sort of thing that you might find in an Excel Spreadsheet – for example if I wanted to make a list of browsers and their known bugs a table would be totally acceptable.
Using a table to layout the design of your site is not an appropriate use, the main reason for this is that it means that a text only browser (or a speaking browser) can’t follow the natural flow of the text and could end up reading the page in totally the wrong order!
When you use CSS to position elements on the page, you can lay out the text in a logical order so that it can be â€˜readâ€™ normally with no style applied. All the positioning comes from your stylesheet and so is ignored by anything that doesnâ€™t read CSS.
The benefits of using CSS for layout are further reaching than just helping accessibility. If you wish to change the layout of a CSS based site then all you need do is change a few settings in the linked stylesheet and all the elements move into their new places across the site. You can change the entire look of a CSS based site in just a few minutes – compare that to having to open and edit page after a page of complex tables.
It all sounds great but I get too many Netscape 4 users to do this
Standards compliant, CSS based layout doesn’t have to mean losing backwards compatibility. Have a look at this site in Netscape 4; still with me? Yes, it looks different but if you had never seen the site in a newer browser you wouldn’t know that, and by allowing small differences I get all the above benefits of standards compliance and accessibility without excluding the version 4s.
This is the future, US and UK government legislation has already meant that many developers have had to franticly get up to speed on accessibility issues, we could find similar legislation applied in any area at any time. Our clients are starting to understand much more about the web, it isn’t a great mystery anymore, I can see a time not so far round the corner when clients are going to ask the question â€˜â€¦ but is it accessible?. By being prepared for the changes, by understanding the issues and working towards getting it right we can all be a force for change change for the better.