These postings are provided "AS IS" with no warranties, and confers no rights. You assume all risk for your use.
Anthony Bartolo Twitter | LinkedIn
Stephen IbarakiIndustry AnalystFCIPS, I.S.P., ITCP/IP3P, DFNPA, CNP, FGITCA, MVP
My daughter-in-law asked me if I could completely rebuild and upgrade the website for her law practice. Wishing for her to make lots of money to help take best care of my grandchildren, I agreed :). This was to involve something of a makeover to improve what had originally been rather poor use of HTML in the page design (typically complex and overuse of tables) and to add secure on-line completion of forms pertaining to various legal transactions. Incidentally going to online forms has boosted her business quite substantially and improved the efficiency of handling the data submitted by her clients.
For some time I had been meaning to learn much more about Cascading Style Sheets (CSS). So I thought that this would be a good opportunity to “persuade” myself to make the effort. Armed with two very good and practical books (CSS Anthology and CSS Cookbook – both from O’Reilly) and a good on-line syntax and properties reference, of which there are many (http://www.blooberry.com/indexdot/css/index.html), I set about learning much more than the basics which I had used before, ie. get into page layout without tables, text based (rather than graphics based) menus, etc..
As I got into it I really began to appreciate the power and elegance of CSS especially in simplifying page layout issues, where tables had been “king” for so long. Using tables is very tempting because it is intuitive and tended to be taught as the way to layout web pages even though that was never their original purpose. However, the overuse of tables can be a “nightmare” when it comes to even making the simplest of changes. Suddenly everything goes “crazy”. At this point it is useful to bring in the behavior of different browsers, ie. it is well known that different browsers handle complex HTML differently, tables and frames being two of the favourite “villains”. So for public websites you were always left with develop on one browser but you had better test on all of the popular ones; what a pain!
Naively, I pushed on with my CSS “revolution” only to discover to my dismay and disappointment that we have swapped one problem for another. There is no question that CSS is the way of the future but do you think that all browsers have interpreted/implemented the supposed “CSS standards” the same way? We couldn’t be that lucky. In fact in many respects the situation is now way more complex. At the back of the CSS Cookbook there are tables listing the CSS features that have been implemented in different browsers including IE 7. And heaven forbid that there are “undocumented features”, ie. “bugs”, resulting in odd, and definitely not standard, behavior. A little thought made me realize that the power and flexibility of CSS has probably created much more complex algorithms to figure out how to layout a web page than with just HTML. One of these days, please, can we all “sing from the same hymn sheet”?
The upshot of all of this is that I spent as much time trying to figure out which CSS features that I can or can’t use, and how to use them to get my desired result, as I have in learning the basics in the first place. This is where the books were really valuable because the sample CSS code “documented” the known “undocumented features”. An example might illustrate my point. I was doing the development work using IE7 and testing in IE6, Firefox and Opera. The W3C standard includes a CSS statement, “display: inline-block;” which I am using as part of text menu display syntax. This works just fine in all my test browsers except Firefox. I then discovered that the equivalent statement for Firefox is the totally non-standard and somewhat obscure, “display: -moz-inline-box;”. So how to make this work with all of the browsers is the next challenge. I couldn’t find any reference material so trial and error was the only way. It turns out that Firefox accepts and uses the first statement that it understands and ignores anything that might try to change that later. Whereas the rest work the opposite way, ie. they use the last statement that they recognize. So it became a question of the order to place the 2 statements in the CSS file. That is Firefox first followed by the W3C version. In effect Firefox sees “display: -moz-inline-box;” and uses that and the rest ignore it and use “display: inline-block;”. This is just the tip of the iceberg. There are now a series of well known more complex cross browser CSS “workarounds” which have been devised by individuals and in many cases their names have been associated with them. The example illustrated here hardly qualifies for the “Jones workaround” since it is very simple I am sure that is probably documented somewhere even if I couldn’t find it.
This might all begin to sound that I regret going down this particular path. That isn’t actually true. In the future I will always think in terms of how I can use CSS in any web page design or re-modeling exercises at the outset, warts and all! One can only hope that the latest CSS features defined by the Standard will gradually appear uniformly across browsers and the “bugs” will be eliminated. Did I actually write that or was it just wishful thinking?
My purpose in writing this is in the hope that if you are contemplating a major switch to using CSS (and you should) you can be forewarned in order to be forearmed. Standards are great things but there is no guarantee that is what you are going to get!