The Downside Of Css, Oop And Standards Compliance CSS has disadvantages as well as advantages

Two areas of web development, CSS and OOP have been accorded the status of a religion, maybe even a super-religion by a large segment of the developer community. The syncophants of CSS and OOP worship at the temple of the W3C gods. Insult whatever is the religion of the last church they attended, and you may get just a shrug, but suggest it may sometimes be better to use an HTML attribute than a CSS style, or that it might be better to write a few lines of unique code inline instead of packaged in a class, and you will surely get a vociferous response.

 

Once upon a time, some up and coming web developer, maybe this author, was called into the office of the Big Boss. On the boss' computer screen, the announcement of the major new product release was showing. It had a problem: the margin of one section of text was a bit off and it looked out of place and ugly. It was an announcement that had been created by a junior web designer under him, who had just quit for another job. " I called on you JD (maybe not his real initials) because Bill the department manager said that you're the best we have, and this is critical. The release of the new Omega package is Thursday this week we have to have that announcement up, but golly it's an embarrassment looking like that! I need someone I can depend on to get it fixed right away and I'm sure you're the man.

 

Our hero, JD the web developer, left the bosses office with the big smile on his face walking on air feeling very elated that he would have the opportunity to impress the big boss and possibly even get a promotion and all he had to do was just fix a simple HTML mistake. JD wasn't really much of a web designer, he was more of a coder, but he figured this would be simple, so he went back to his office and confidently set to work.

 

He started by looking at the generated HTML source of the page and found where the errant margin was. The HTML tag containing the offending text was styled by both an id attribute and a class attribute. He looked at the top of the page and saw that there were three stylesheets that were linked and two that were imported. JD did not know which of the stylesheets held the style he was interested in, so he looked at the first one. It was a jumble of style rules in no particular order that had been added over time by multiple developers. Finally, using text search, he found the class corresponding to the one in the offending tag.

The bad margin that JD was trying to fix was 5 pixels too wide, so he changed the style to decrease the margin, saved the changes, and then took a look on his testing server. The margin had not changed, it was still 5px too wide! Perplexed but still confident, he closed that stylesheet in his browser and moved on to examine the next one for a clue for why the margin didn't change.

 

Now those of you readers that have some experience with CSS and web design yourselves may have some inkling of the sad turn this tale is about to take...

 

After spending the next hour examining the other two linked stylesheets, JD had found no other style that would influence that margin width. He was feeling less confident and starting to sweat, as he noticed the boss passing by in the hall, casting a concerned look towards JD's cubicle. Then it occurred to him, something he had seen but ignored in the first stylesheet he had examined: a class of the same name attached to an HTML selector! He made the change to this rule also, and he was so confident that this would fix the problem, and so anxious to finish the job for the boss, that he uploaded the revised stylesheet to the server without bothering to check it first on the testing server.

 

Our hero did have enough sense to navigate to the page with the error in his browser after uploading the stylesheet. To his surprise, the margin was still off! It had not changed. He undid the change that he had just made to the stylesheet and uploaded it again. Being generally an optimistic sort, JD was looking at the bright side of the situation which was that he had not made the mistake of prematurely reporting the problem as fixed. He was taking a breather for a moment, sipping on a cup of coffee and considering the possibilities, when the head of his department, JD's immediate boss, Bill rushed in with a look of panic on his face and his voice trembling with fear "Every margin in the center column of every page of the site is messed up! The CEO is furious!"

 

Like a bolt of lightning, it struck him: JD knew exactly what the problem was, and it was his fault. He had neglected to undo the first change that he had made to the stylesheet, before uploading it after the second change. Every page on the site used that stylesheet. JD admitted no culpability, merely feigning a slight look of irritation that implied that the problem was the fault of some subordinate. He was really hoping that somehow he could take credit for fixing this new problem and distract attention from the fiasco of the original problem.

 

Soon it became clear that the big boss was not inclined to give anyone credit for anything at that point. He stormed into JD's corner office cubicle with the window that JD so coveted, and red-faced with his voice a couple of decibels louder than usual said, "I thought I could depend on you to get the problem with the announcement fixed. Nothing has been fixed, and there have been even worse problems! I just got a call from the CEO and he is very concerned about this". "Well, I did fix the big problem with the rest of the margins," JD ventured defensively. "Which never should have happened in the first place and is another problem with your department!" the boss blustered. At this point, JD is cringinging with fear and hoping that he will wake up and discover this is really all just a nightmare (maybe it is). In the meantime, real or no, he has to appease the big boss so he guarantees to have the problem fixed in one hour without fail. "Both our jobs may be riding on it" the boss replied.

 

Now feeling very unhero-like, JD our web developer was working on the most important task of his professional career: he has one hour to shift a paragraph of text on a web page by 5 pixels. Wild thoughts of transparent spacer images, and wistful thoughts of how easy it would be to dump the CSS styles altogether and use simple, dependable, deprecated HTML techniques to align the paragraph where it is supposed to be. He knew however, that it would never get by the most feared employee in his department: The Validator. The Validator was a rather stern ex-schoolteacher whose job it was to check all work done in the department to ensure that the code validates against W3C and company standards. It would be so easy to ditch the CSS and simply use a table with a padding attribute instead, to position the text. So easy, but so impossible because such a deprecated constructs would never make it past The Validator.

 

As JD's allotted hour was drawing short, he was getting desperate. He had compiled a list of all the styles in all of the linked and imported style sheets that he thought could possibly affect the text in question. He vaguely remembered something from his university days about how to calculate the order of precedence of CSS styles using statistics and mathematics. He was so absorbed in attempting this calculation that he didn't notice when the big boss walked in behind him. He was startled when the boss asked in a calm, worrisomely sympathetic voice that rose in pitch at the end to a threatening overtone. "When I get back to my office and I look at the announcement on the internet it will be fixed right?" At that moment, JD could sense that "No" was not an option so he lied, "Yes sir. All fixed, and I'm sorry it took so long," even managing a weak approximation of a confident smile.

 

Now JD had approximately one minute to fix the problem and upload the fix to the server, maybe longer if the boss stopped to flirt with the cute secretary down the hall. He was so confident that he had just found the style rule that was causing the problem, that he uploaded the fixed stylesheet live to the internet, and holding his breath with anticipation, he navigated to the offending page with Internet Explorer. Hallelujah! It was fixed and he was saved! He called the boss to let him know the good news. In the back of his mind, he knew that he should have check the page in Firefox before calling the boss, but partly because of confidence in his fix, and partly through lack of confidence in it, he didn't.

 

More jubilant than he had been in a long time, and now feeling like a hero again, JD heads for the door, leaving an hour early to have a celebratory cocktail or two at his favorite after work joint. He was intercepted by Bill his department head on the way to the door. "I'm sorry JD, I looked at your fix, and it works fine in IE but it's a disaster in Firefox. And, unfortunately for you, the Vice President (Big Boss) uses Firefox on his computer. You have until the end of the day to clean out your cubicle".

 

Such tales are to be heard in the web programming world also, because there are strong similarities between CSS and OOP (Object Oriented Programming). Conceptually, CSS and OOP are almost identical. Both are means of packaging code in standardized, reusable packages. In CSS, the packages contain presentation rules, and in OOP, code. Even the terminology is similar because classes refer to these packages of reusable code in both instances.

 

This object oriented concept has proved to be very valuable and successful when used for code or styles that really do need to be reused, but it is really the proverbial double-edged sword, because

although it makes it very easy to make changes to multiple pages all at once, it can make it very difficult and dangerous to change just a single instance. Just ask JD in the story above.

 

And how about styles or code that are only used in one place with no need for reuse? Should these also be packaged under the OOP/CSS framework? The W3C gods have decreed that practically EVERYTHING must be packaged in the OOP/CSS framework. It is blasphemous (deprecated) to use such a primitive structure as a table and only a bumpkin would ever write any inline code.

 

Unfortunately, many developers take these commandments of the W3C to heart, regardless of how difficult or impractical they may be, and end up with code that is both much more difficult to write, particularly considering the need for cross-browser compatiblity, and also much more difficult to understand and maintain than necessary. If simple, proven, inline coding techniques are more appropriate for a unique task, why not use them? Loosen up W3C, make things easier, not harder (please do not report this article to the W3C, or the author will probably be stoned to death).

A nice little story but I don't think there is any relation with CSS and OOP except that they both have classes and even then CSS classes are only used in one way. The story you told is something we all face in building web pages that are cross browser compatible and its not in my opinion W3C's fault. They are the ones trying to solve this problem but its companies that build browsers that don't render elements or follow their guidelines like internet explorer. I'm sure we all know how much differently internet explorer chooses to render certain elements.