Non-Standard Code Hurts The Bottom Line
May 14, 2004 | 
19 Comments
It’s time to talk Web standards again. I’ve been bitten hard by the non-standard code bug and it’s time to roll out a few more big benefits of going with Web standards! This time by talking about how non-standard code can hurt your bottom line.
Over the last few weeks I’ve been juggling quite a few projects down at the hospital as well as a couple freelance gigs. It’s been a less than ideal situation, but hey, that’s par for the course.
What’s made it particularly difficult with this batch is all the non-standard legacy and proprietary code I’ve got to deal with. It’s been a nightmare and it’s really driven home for me the absolute need to make an effort to go with Web standard code whenever possible.
The Rundown On Lost ROI
These projects, simply put, are taking much longer than they should and they’re a huge resource draw across the board. It’s not been pretty. The Return On Investment (ROI) on them has been a joke, especially when compared to the projects I work on that are built with Web standard code.
It’s a huge difference. We’re talking days of development time and probably thousands of dollars lost to mucking around non-standard code.
And that is just this go-round! What happens when we have to go back to this code? It’s a scary thought.
A Few Problems With Non-Standard Code
Both of these projects entail the customization of some kind of proprietary Web solution. Both have proprietary markup that needs to be learned to some degree (one has a manual of about 100 pages, just for the custom tags) and both have lines and lines (and more lines) of non-standard HTML to sort through.
Now the custom markup and code for these applications is one thing. That is something I can deal with. The non-standard HTML? That’s another story.
It is an absolute mess. There are improperly nested tables, deprecated tags (font tags, small tags) inline styles, the works. You name it and it’s probably in there. This makes it very, very hard to customize, which is crazy because that’s what it was built for!
CSS anyone?
I’d spend hours just trying to sort through it all and then, when I feel like I’ve got enough of a handle to make a change, invariably I break something. It’s almost like they people who coded it wanted it to break.
I’m not even trying to bring any of this up-to-snuff. I’ve accepted the fact that these pages will not validate and could very well have many cross-browser display issues (One of the solutions is, for all intents and purposes, IE Win only, even though they claim to support, ahem, Netscape). I’ve been coding them with no regard to Web standards not only because it doesn’t matter, but because if I don’t things don’t work right.
That’s right, Web standard code (mostly CSS) breaks this stuff. Have you ever tried to plant an deeply nested table into a tableless layout? It’s tricky business. Almost works like a virus as you have to add even more tables to get it all sorted out.
On another distressing note, both of these solutions come from large, well known companies who should have the resources to at least get the basics right.
I’m not talking about going tableless, or even simple XHTML. I’m talking about properly nesting tables and tags. Hell, just closing all the tags would be a big help. To be totally honest I was shocked to see the tag soup in there.
ANYway, I don’t want to bore you with any more details. Let’s just leave it at this — it’s been way more work than it’s been worth. Had these been coded with simple, valid HTML 4.01 I’d have been able to shave days of the development time. No joke.
Why You Should Care
The benefits of Web standards for today have been outlined again and again, but in my mind the real benefits will come down the road. These problems I talk about are fairly common and don’t always end in a frustrated developer.
Non-standard, inflexible code was one of the main reasons we ditched our CMS down at the hospital. We were paying them a pretty nice fee for support and licensing every month that they might have been able to hold onto if they’d done it right the first time.
Also, not that it’ll make a damn bit of difference, but I’m going to write both these companies and let them know what I think about their products. I’m their customer and lets just say I’m far from a happy camper.
In these particular situations these companies don’t stand to loose any money…yet. The only real cost has been my time and effort, which while it sucks for me and my clients, it’s not a concern to these 3rd party vendors.
However, it could cost them down the road if we don’t re-up with them and could really harm them down the road if they don’t take care of it. Just to move this stuff to valid and standard markup would be a very difficult task.
What can you do to avoid this? Use Web standard code of course!
I realize that you can’t always go with Web standards. I’ve been coding like it’s 1998 all week on these projects and frankly there was no reason to do anything but that. Not my code, not my problem.
However, if you are working on a project from scratch, something you own yourself, something you know is going to have to be maintained going forward, or could be sold to a 3rd party, Web standards should be your only choice.
Wait, no let me restate that. As much as I don’t believe in rules for the Web, I think using Web standard code whenever possible is as close to a rule as you can get.
Filed under: Web Development
Comments
1. David Barrett said:
Keith, have you thought of using a post-processing parser, to turn that unmanageable code into something more manageable (and possible to validate?).
Bear in mind I have no idea how long this will take (it depends on the complexity of the markup involved) but it’s certainly a possible solution.
Posted on May 14, 2004 02:43 AM | #
2. David Barrett said:
For "post-processing parser", read "wrapping parser"
Something like:
Their code -> parser to fix this code -> program to put fixed markup in final location
Posted on May 14, 2004 02:47 AM | #
3. kartooner said:
Keith, lately I’ve been involved in similiar issues wherein the client’s site is constructed in what I call HTML Hell. More specifically; tag soup, deeply nested tables, malformed code, etc.
It got to the point where I had to rant about the issue on my site. Reading your article, however, made me feel better. Knowing that this issue is prominent and attempting to convert said company to web standards always ensures the “not in the budget” viewpoint.
Some of these companies are less interested in how in works than how it looks. As someone commented, they rarely know the difference from sloppy, spaghetti code as opposed to clean, standards-based code.
Posted on May 14, 2004 05:31 AM | #
4. Georg said:
Somewhat along the same lines as Dave Barrett’s comments, using HTML Tidy works for me.
Took a while to set up and get used to, but it’s pretty stable and says: “bye-bye tag-soup” to almost anything (or thrashes the page).
The job isn’t done when HTML Tidy has finished its part, but it sure is a time-saver.
I agree that “using Web standard code whenever possible” is as close as you can get to a rule. If only that “rule” was accepted by those who always see it as an either / or. We get bashed for putting non-valid code in our designs because not all browsers support the pure, valid, code. Looks like those who write non-valid code all day long has an easier life (for the time being).
In time the bottom line, money, will decide who survive in this business. Let’s hope QUALITY pays - some day.
Posted on May 14, 2004 05:59 AM | #
5. jake said:
Keith, I know exactly what you mean. Luckily most of my freelance projects are small so cleaning up tag soup doesn’t take too long.
But at work (http://www.amphenol.com), I constantly have to muck through crappy code. The main site I linked to is my baby, I work at headquarters so I get to work on that site. I can go on and on with horror stories where decentralization makes things screwy cause most divisions have their own self managed sites (luckily I can get at a few of them and clean them up as I go along). and I have no control.
But I’ll just give one example when I got really frustrated. We have a search tool, which I have no control over and am currently trying to replace (though no one wants to pay for it, they just complain about the current offering). It was suggested I just have a new window pop up with the search results from their tag soup. Well, trying to be a designer, I just couldn’t have that, so I used a back end process to grab the results as text and I ripped out all the tags and replaced it with cleaner code as best I could. Luckily this being my ful time job, I can be anal about stuff like that. ;)
Thanks for letting me vent, I’m the only web guy around here so no one else really follows what I’m saying when I rant, they just smile and nod. It is true that you can’t always get away with web standards, but do it whenever possible.
Posted on May 14, 2004 06:33 AM | #
6. -b- said:
Molly posted a related WaSP buzz topic.
http://www.webstandards.org/buzz/archive/2004_05.html#a000341
Posted on May 14, 2004 06:48 AM | #
7. Paul G said:
I’m glad I’m not the only one stuck working with a system that will break if I use web standard code. It’s very frustrating to spend hours working on something that would take minutes were it not for the ocean of invalid code that I have to wade through. I still use CSS as much as possible (although it winds up being inline or in an invalid <style> tag in the body), but I have to be extremely careful about my selectors, especially with tables, or I’ll end up screwing the entire site. How on earth did we ever get by with this sort of mess?
Posted on May 14, 2004 07:07 AM | #
8. Laurens Holst said:
Hey, um, <small> tags aren’t deprecated… Well, their use is discouraged, I guess (as much as <i> and <b> and everything else from chapter 15 of the HTML spec). But even in XHTML 1.1 Strict they can be used without invalidating the code…
~Grauw
Posted on May 14, 2004 07:44 AM | #
9. Keith said:
Laurens – Hmm, ok, I had just assumed that it was because it’s useless. Maybe it’s not “officially” depricated, but I’d never use it. Good to know anyway, I guess.
As far as David’s and Georg’s comments about some kind of HTML parser like HTML Tidy:
That isn’t an option really. I don’t think something like that would have worked well and to be honest, and this is code that I’m forced to deal with. It’s not my code, I don’t “own” it. It’s also more application type code and very complicated. My guess is HTML Tidy would break everything.
HTML Tidy is a great solution and if I did own this code you’d bet I’d start there. Unfortunatley these projects, for a few reasons, it just wouldn’t work I’m afraid.
My goal here is not to clean the code, just to get it working right.
Posted on May 14, 2004 08:45 AM | #
10. Britt said:
As a web team of one, I have purchased a few ColdFusion apps and am horrified by the code. My first step is to just strip out all the tables (unless one is actually used for data), font tags, etc., and just start over. I love the stylesheets that come with them as well—tons of classes with names like .td and .body.
I’ve noticed many CF coders leave out closing tags, a habit that was picked up from popular CF books. They try to make the application look cool, but I’m not after that. I just want the CF code. If their HTML is that bad, I wonder how much better the CFML could be?
Posted on May 14, 2004 08:53 AM | #
11. Seth said:
Man, I’ve been having the same problems too. I’m having to recode sites that were originally created with something as old as “Hotdog” or “Hotmetal Pro”. Heck I wouldn’t doubt if this code was spit out from Frontpage 1.0 :D
I have definitely felt the absolute need for web standards as well. It just makes things easy. Besides you don’t end up with 100 unecessary empty font, or p tags. :)
Posted on May 14, 2004 09:32 AM | #
12. Ryan said:
After dealing with a similar issue recently (facing being forced to deal with a web-based KM solution that spits out nasty code that’s riddled with font tags and is just *not* easily stylable), it felt good to read your rant, if just to remind me that other developers are in the same boat.
Posted on May 14, 2004 11:20 AM | #
13. Sean King said:
I couldn’t agree more. I’m in a similar situation as Jake (working for a large electronics company) and the intranet site markup is pretty bad. Nearly all of the pages were created through Dreamweaver 4 templates, the CSS styles set are all classes. You would think its not that bad, but anyone can attest to DW4’s predilection for non-standard markup (the team has just put in for MX 2004, which should help).
But this situation doesn’t improve unless you get everyone (all the people who touch markup) on-board. To this end, I’ve made it a personal goal to teach my co-workers standards-based design. If I can get the team thinking about and utilizing standard code now, over time the site should gradually be brought into some level of compliance (I’m certain we’ll have to overlook the “Tables for Layout” issue).
Posted on May 14, 2004 11:42 AM | #
14. Jennifer Grucza said:
You think millions of font tags and improperly nested or closed tags are bad? They’re even worse when they’re being spit out with out.println() inside Java servlet code! And when all the colors, font sizes, and other values are all inline, instead of at least being pulled out into static variables that could be reused!
It felt so good to completely rewrite the whole web layer using CSS and JSPs.
You would think that programmers would at least be able to write well-formed HTML with proper nesting - but maybe some of us are a little too dependent on the compiler for error-checking.
Posted on May 14, 2004 12:33 PM | #
15. Justin said:
Maybe a bit OT, but along these lines: When you make estimates for projects, how do you handle the issue of tag soup? Sure you budget time to deal with the junk, but how do you explain it to a customer who doesn’t know (or care) about the difference.
There’s a program I haven’t heard of in a while.. ahh the memories…
Posted on May 14, 2004 12:44 PM | #
16. Bryan said:
I will tell you one thing, I want to see the letters and the replies you get when you write the company, that would be great to see.
Keep up the good writing, I love reading this site.
Posted on May 14, 2004 01:23 PM | #
17. Anton said:
Man, I feel your pain - except maybe on a slightly larger scale…
I work for a major insurance company. I try to insert modern code whenever possible, but there are always multiple variables that are hard to deal with, especially legacy code.
The site was re-designed about 3 or 4 years ago, when tables and font tags weren’t yet bad words. Thousands upon thousands of pages were changed from even older pages, taking up hundreds of hours in labor. Any new re-design suggestions get looked at with a very narrow eye on an even narrower budget.
Ehh… hope this doesn’t come out too choppy, I had made a longer reply, but changed most of it, deleted the other half, and added a few bits for good luck, then lost my train of… what?
:)
oh, and I use a lot of GREP in my Find/Replace dialog with BBEdit. With grep power comes grep responsibility!
Posted on May 14, 2004 01:46 PM | #
18. Rob Cameron said:
Great article!
The problem comes in convincing the powers that be that they need to update their code. A commenter on another blog summed it up as their boss saying “why fix what works?” You can tell them the benefits all day (smaller files, easier changes, cleaner code) but in the end it’s just geek-speak to them. For my company’s site (www.amronintl.com) I didn’t ask/tell anyone anything, I just went ahead and did it the right way. Luckily I had the “luxury” of starting from scratch. It’s the ones that need to convince someone to let them spend the time converting old pages (which takes away from time they could be doing something “more productive”) that will have the hardest time. Sometimes I feel a little bummed that I’m saving the company all this time and money and they don’t even know it! I need more recognition, damn it! :)
When I redesigned my company’s site I had just finished reading Zeldman’s book. Going through the old code was a complete nightmare, so I just started from scratch. We’ve got several mini-sites that use the same base pages, just different CSS to swap color palettes. I also went with XHTML 1.0 Transitional and a couple tables as we want the site to have at least a little bit of layout for people with REALLY old browsers. Last month I was able to completely change the look of the homepage in a day thanks to the wonderful CSS that was there to begin with.
We still convert old product pages into the new standards-compliant style. When going through the old code, my RegEx replacer sometimes removes 1000+ useless HTML (deprecated tags, attributes, etc) for a single product page! CSS rules all.
Posted on May 14, 2004 01:54 PM | #
19. Seth Thomas Rasmussen said:
Word. I hear ya, man.
I recently was given both the pleasure and excruciating misfortune of converting some 40 pages of a site done in GoLive several years ago to more modern, standards-compliant methods.
Pleasure, because in taking up standards compliance as a focus over the past several months (yeah, I just caught the bug.. I can’t help it, it’s just when things fell my way!) I’ve come to view web development more as what I do… not just a job, yeknow?
Pain, of course, because of what you are just describing. I mean, when you open a form set in a byzantine set of nested tables in Dreamweaver, and it can’t even display it properly in design view because it’s such a mess, you know you’ve got problems.. ;)
Posted on May 17, 2004 08:00 AM | #
Comments are now closed