Stop Writing Garbage Code, Please

Posted April 13th, 2007 by Mike Cherim

As most of my readers know, one of the things I do is make themes and templates for WordPress web logs and stand-alone sites. The themes and templates I make are accessible, universal, standards-compliant, and strictly valid. I take a lot of pride in what I produce and I try to turn out nothing but the highest quality stuff. Once users download the fruits of my labor, my responsibility of quality control ends and the users take the reigns. That’s when things sometimes go awry. But in many instances, it’s not the users’ fault.

Can’t Blame the Users

Users don’t purposely try to destroy the quality of what I produce, but in the process of adding third-party code snippets, add-ons, and plugins, things can sometimes get pretty messy. As I wrote, it’s not the users’ fault per se, they trust the code they get from the various providers, the weak link is that the code they download and install per the instructions, in a word, sucks.

Time to Make it Right

This is a request to anyone who provides code snippets, plugins, widgets, or add-ons on the web. This would include anyone who provides plug-and-play code to the general user. It’s time to update, to upgrade, to get with the program, and pull your head out of your… [Pop!]. This has been brewing for a while and this is, well, a rant. I’m tired of it and a bit frustrated. One careless coder pumping out nothing more than a few lines of code can adversely affect thousands of sites and make thousands of combined hours of extra work for developers committed to doing things right. A few minutes of extra effort on the part of the original producer is all it takes to get it right, yet, for some reason, it seems that’s asking too much.

The Back-Breaking Straw

As I noted this has been brewing for a while. What pushed me over the edge, so to speak, was a adding PayPal order form to a soon-to-launch blog I’ve been working on recently. The site owner generated the form code (or regurgitated might be more apt) at the PayPal site and sent it to me by email. As soon as I saw it I was shocked by the poor quality. It was a form that was going to be installed on an Extensible HyperText Markup Language (XHTML) site, yet it was only provided as loose HyperText Markup Language (HTML). I had to fix that. Additionally, it had no fieldset, no legend, no closing tags (as required by XHTML), no labels, even a deprecated inline attribute (border="0"). Oh, and it was laid out with included table markup. I was stunned, but being it was something I was installing on one of my projects I was obligated to fix it. I made it accessible and valid. I recognized it for the garbage it was, and being that I know this stuff, I was able to make it right. But it’s something I shouldn’t have had to do.

What PayPal Doesn’t Know

The form markup from PayPal came with select options (a pull down) so buyers could select a quantity. The options were left open, <option value="1">1, which is fine with HTML but not XHTML. I fixed that by closing them: <option value="1">1</option>. This made it valid, but the quantity didn’t work. I didn’t know why so the client asked PayPal tech support. They got back to him quickly and stated “the options can’t be closed” as I did and went on to explain that the code must be inserted “exactly as is produced on their site.” What?! I knew that was an inaccurate response. For troubleshooting purposes I pasted the generated code and it didn’t work either, as I suspected. I dug into it to find the real cause. I determined the quantity didn’t work because an incorrect name attribute was supplied. They had name="on0" and it needed to be name="qty". Once I did that the form was accessible, valid, and proper, and amazingly it worked.

Different Flavors of Markup

It bugs me that even though there’s a ton of XHTML web sites on the web, most providers only offer their code in one flavor: typically just HTML. Why? How hard would it be to offer it in both X and HTML? Are they afraid they’re going to confuse people? That’s probably it, but I see that as a weak excuse at best. People running web sites need to learn what document type is being declared. And if PayPal or whoever doesn’t want to confuse them, then they should attempt to explain the difference — or at least show how site owners can tell so they know which code block to choose. I typically offer my stuff in multiple flavors so users can choose the right thing. For example, my contact form script has a variable in the configuration that totally changes the form’s elements to be valid with either mark-up language used. Doing this allows people to be valid and proper, without them having to dig into the code to make it right. One small effort on my part equates to huge benefits Internet wide.

Other Way-Too-Common Problems

I’m not trying to pick on PayPal. I see all sort of problems out there and I’m done naming names. Forms just happen to be one I see often and this PayPal issue was a lot harder than it should be for a copy-and-paste bit of code. It was aggravating. Aside from forms missing their elements, here are some other issues I see a lot:

Please no border="0"
As I mentioned previously, the form’s submit image had the border attribute. This doesn’t make me want to party like it’s 1999, but it reminiscent of that era. Style sheets rule and they’re all over the web. If the style sheet removes the linked image border then it doesn’t need any help from that attribute. And it probably does remove the border as that’s most common, but if it doesn’t, maybe the web site’s owner wants it that way. Same thing applies to all sorts of code blocks that contain imagery. Stop using the border attribute.
Really old font-color="gray"
Like I just wrote, let the style sheet do the work. Font tags are deprecated. Stop using them. If you want to be helpful — which is apparently the case since you’re tying to color my text — please do it by providing a class or put your script in ID’d container that I can refer to or inherit from. Also, since this might be for people who don’t know this stuff, provide an explanation and some example styles.
Coders don’t speak script language="javascript"
I used to know a guy who spoke JavaScript. But that’s because he was a telemarketer who just happened to sell coffee. Stop using the language attribute when defining a script. I thought this was getting to be common knowledge, but I still see if all the time. To define the script, use the type attribute. In the case of JavaScript, use script type="text/javascript". Save the language for your homies.
Save a tree, ditch a data table
Want to do your part to save planet Earth? Help the environment by not cutting down trees to make a bunch of worthless tables that have no place on most modern sites. I get tired of having to pull out a claw hammer to de-construct tables. If your code produces tabular data then you’re doing users a service, otherwise find another way.
SoMe non-lowercase CODE
I wrote “non-lowercase” because that best describes CaMeLcAsE and UPPERCASE. Markup should be written in lowercase. Writing things like <P></P>, or worse, a mix of lowercase and uppercase, has no business being on a contemporary site. Same goes for scripting events and whatnot. Please develop proper and consistent practices.
Where are the missing attributes?
I see this a lot on image markup. The width and height attributes are missing. They are still legal, still useful, and actually enhance site performance. If the width and height is specified, the browser knows what space allocation is needed for the image and can properly render the page before all of its content is downloaded. Also be sure to include the alt attribute but don’t be too quick to offer alt text. Seldom does it enhance the user experience so you need to understand how this attribute’s text is delivered to users who need it. More info is available in my The Alt and Accessibility article I wrote a while back.
A trial link separation
If your plugin or add-on code contains a bunch of links, please make sure they’re properly separated. This was something I experienced recently, and I won’t mentioned the maker or the plugin, but I had to fix it. It wasn’t hard because I have some knowledge about the scripting language used and web accessibility, but I shouldn’t have had to fix it to begin with. There are a few basic rules which help retain inherent web accessibility, so try to gain understanding of these and make your code compliant.

Help Spread the Word

In my comments please share some of the atrocities you’ve seen that I may have missed. And more importantly, please help me spread the word so the guilty see this or hear about it. You can do this by referring to this article, or simply blog about it yourself. If a significant number of voices sound off, maybe the guilty parties will hear the plea and maybe spend a few moments making their stuff right. This will go a long way towards making the web in general a more standards-compliant and accessible place.

39 Responses to: “Stop Writing Garbage Code, Please”

  1. Elliott Cross responds:
    Posted: April 13th, 2007 at 4:23 pm

    I couldn’t agree even more! You said it all, and I have experienced this on my sites personnally. I was using a form on one site to allow users to sign up for a free woodworking catalog. It was junk, using tables, and when I tried to clean it up for validation, it failed to work properly.

    I contacted the vendor, advised them of the issue and asked when they were going to release something, well, compliant with standards. Needless to say, I hung up while the silence on the other end went on.

    Well, said Mike, and keep up the push. The more that accessible and standards compliant markup is written about, blogged about, and spread, hopefully the more that everyone will begin the amazing transformation to standards and semantic markup!

  2. David Zemens responds:
    Posted: April 13th, 2007 at 4:32 pm

    Ditto what Elliott said. You are a great champion for valid and accessible web design. Heck, if someone as new to web design as I am can learn about accessible design and valid markup, anyone can if they simply take the time to be interested and to learn. It’s a great feeling to design a site that is valid, accessible and Priority 3 compliant. It’s a real feeling of accomplishment.

  3. Ty responds:
    Posted: April 13th, 2007 at 5:45 pm

    Nice little rant Mike, I wish spring would hurry up and get here weather-wise, so everyone would stop with the cranky ranting. Seriously, lots of good info here. Somebody’s got to pound the pulpit of standards.
    A little bit more pulpit pounding might just result in less code having to be sent through the wringer every time.
    Tnx mate.

  4. Joe Dolson responds:
    Posted: April 13th, 2007 at 8:02 pm

    Bad code is such a frustrating experience…sometimes, for simpler coding projects, I tell clients that they have two options: I can implement a piece of 3rd party software for them, or I can write them something just for their site and their situation. It won’t make a difference, time wise…

    I’d LIKE to believe that using a 3rd party resource would always be a time saver, but sometimes it just isn’t.

  5. John Faulds responds:
    Posted: April 13th, 2007 at 9:47 pm

    I’m not that surprised by your PayPal experience, Mike. What I was surprised by recently was I built a site using a CMS which has a solid standards-aware designer user base and found some of the default template code to be really ordinary - things like stylesheets in which the font-family and color were redeclared for every single rule.

  6. Gill responds:
    Posted: April 13th, 2007 at 10:11 pm

    Now you just knew I’d have to comment on this one given my recent rant. :-)

    I’ve been down the Paypal route with their shopping basket code on a site with several dozen back issue magazines. Fun isn’t it. It’s the same with affiliate code,

    Please copy and paste this code and place it in your page

    You have to be kidding me! You think I’m going to stick that load of garbage in my nice clean page? I thought I was on a one woman crusade. I rewrite it and email it to them. So far only one has bothered to change it.

  7. JBVoices » How not to build web sites responds:
    Posted: April 13th, 2007 at 11:11 pm

    […] You might also like to take a trip over to Mike Cherim’s excellent article titled Stop writing Garbage Code […]

  8. Tommy Olsson responds:
    Posted: April 16th, 2007 at 1:33 am

    Since very, very few sites are able to use XHTML it makes sense for snippet providers to deliver HTML. Oh, lots of sites use XHTML markup and probably believe they are very progressive and cool, but they serve this markup as text/html, which means they are still using HTML.

    Those missing </option> tags would have resulted in validation errors, but browsers wouldn’t give a toss since they are optional in HTML, and HTML is what you use unless it’s an extremely rare site that doesn’t cater to Internet Explorer.

    I agree, though, that those who provide code snippets to the public should endeavour to deliver high-quality code. I’m not holding my breath, though.

  9. Gill responds:
    Posted: April 16th, 2007 at 7:49 am

    it makes sense for snippet providers to deliver HTML

    Yes as long as it’s valid HTML but the garbage a lot of them want you to use is really, really bad. The day I find some javascript that’s not using language= is the day I’ll hang the flags out.

  10. Alex responds:
    Posted: April 17th, 2007 at 9:49 am

    Hi Mike, thanks for starting this discussion. As someone who sits on both sides of the producing/consuming line, it is close to my heart. That said, I need to double-check my plugins and scripts to make sure that I’m not violating the practices I agree with.

    That said, I disagree with your anti-table stance: “If your code produces tabular data then you’re doing users a service, otherwise find another way”. Tabular data has a very real and important purpose, especially when comparing items or sets of data, which may be the entire reason behind using a service, plugin or script. I suggest a shift of purpose to oppose the use of tables to lay out non-tabular data, and to ensure that the producers and consumers understand what does and does not qualify as tabular data. Additionally a recommended method of table production (border, cellpadding, cellspacing, th vs. td etc.) that simplifies consuming and styling of the data would prove invaluable. The tool itself is good, it has just been put to poor use by folks (myself included) who needed layout options back in the dark times.

    Good stuff Mike, I’ll spread the word the best I can!

  11. Garbage code belongs in the landfill! « Multitudes of randomness responds:
    Posted: April 17th, 2007 at 1:16 pm

    […] The other day I was reading a really interesting post from Mike Cherim about various producers of code that write, well, junk! It was really funny to read this as I have had several experiences with various producers of code that aren’t valid or even close to accessible markup. […]

  12. Alex responds:
    Posted: April 17th, 2007 at 2:06 pm

    Sweet, thanks for the clarification Mike!

  13. Megan responds:
    Posted: April 17th, 2007 at 2:33 pm

    Great post, Mike! I totally agree with everything you wrote. As the webmaster of several large sites headaches like these make life so much more difficult. My partner spent hours trying to get phpAdsNew code to be standards compliant. If there was a reasonable alternative, we surely would have switched. Last fall I spent the better part of a week trying to find a web survey application that was standards compliant. When I couldn’t find one I finally decided to fix an open source project to make it compliant. That turned out to be too much work and I ended up coding my own form and learning PHP & mySQL to make it work.

    All of this is rediculous. We shouldn’t have to go to so much effort. And the people who produce these scripts should know that they are losing out on users who will do everything they can to avoid using something that’s not standards compliant. These days standards are becoming a good marketing tool.

  14. How to make any web page print nicely in Opera - responds:
    Posted: April 17th, 2007 at 2:35 pm

    […] P.S. Apparently cranky ranting is going around these days. I guess I’m not the only one! […]

  15. Sparky responds:
    Posted: April 18th, 2007 at 1:01 am

    I like everything you said and agree with the spirit of your rant. But I think it would be useful to your users to mention that your statement “Markup should be in lower case” is a stylistic choice unless your markup is XHTML. Now, all MY sites are done in XHTML and so I’ve developed a preference for lower case markup as you seem to have, but for those people making the (not always unreasonable) choice to write their markup in HTML, they should feel free to write in whatever case they prefer, upper or lower. Of course, they would make my life easier if they did it in lowercase and used closing tags for everything, because I may be moving their dated site to XHTML one day, but it’s certainly not a requirement. High quality code is code that follows standards, and if you’re writing HTML markup and don’t close your tags and use uppercase tags, you’re still following the standard even though I might not like it ;)

  16. Terry McNeese responds:
    Posted: April 18th, 2007 at 8:57 am

    Thanks for all of the good tips, since that’s why I’m tripping around these forums - to improve my coding and make it compatible web-wide. It would be wonderful if there were an easy way to keep things straight and everyone had the objective of keeping code compliant. I must applaud Megan’s (and everyone elses’s) diligence for going the extra mile to keep things compliant.
    On the other side of the coin, the whole thing is just a rant (that unfortunately will not stop the wanton code destruction by these nere-do-wells). If my objective for putting up a website is to inform and be compliant, then your approach of responsibility is justified. But, if my objective of putting up a website (sales, blog, wiki, etc, etc, etc……) is simply to get people to come and take some action (read .. BUY) then as long as the code works for that objective, then I’m good with that! (definitely a marketer’s perspective).
    Since, for the most part, I always try to make sure that my code is as compliant as possible (within the scope of the job), I appreciate your point and suffer from the same responsibility malady from time to time working for various clients (paid and charitable), but it’s also time we drop the crutch. My view on the whole issue has changed dramatically as I’m doing more and more of this cleanup (optimization, if you will). If the end product achieves the objective of the customer as stated in the initial prospectus, then we have achieved a balance (i.e. service performed - service paid for), if it doesn’t, then it is my responsibility to get to the balance point. On the other hand, if the balance point is reached and the customer decides to tip it by adding things that don’t work or are not usable because of someone not doing “the whole job”, then I can only do my best to assist if I am equally compensated to re-reach the balance point (read…PROPERLY PAID).
    Most of the people who are producing this add-on code are only doing it to improve the balance in the bank book, so their concern for “proper coding” is limited. (This might also be said for people who actually code for a living, based on the current recoding job that I’m doing for a customer/friend who recently purchased a large site rewrite for an enormously hefty sum only to get slopped together doo-doo with no real recourse but to go a-beggin’. Ah, the things some of us will do for a couple of premium bottles of vino, but I digress). Bottom line is that we need to keep educating ourselves on the best and cleanest way to write the code, learn to look the other way when some third-party provider endeavours to destroy our ying and yang with their Pablo Picasso coding attempts (oh my gosh, talk about terrorism, try wading through a storefront program put together by an Indian web company to change one little word on the index page) and clearly (and without remorse) communicate the need for a larger check when a customer comes clamoring back after adding on something that “just doesn’t fit in that space!!”
    Thanks so much for the excellent (and clean) tips and keep ‘em coming.

  17. Shane Holland responds:
    Posted: April 20th, 2007 at 10:27 am

    Great article, Mike - thanks for posting. Not to really get into it, but I had implemented Blogger into my website a little bit ago, and I was distraught by the code it generated. For the most part it validated for me as XHTML, but it looked really messy and was placing div style="clear: both" all over. Anyway, I’m going to see if I can implement - assuming I’ll have more control over everything?

    Again - thanks for the article, I’m all-aboard with you on it!

    Take care.

  18. Shane Holland responds:
    Posted: April 20th, 2007 at 8:44 pm

    Are you referring to the div class="clear"?

  19. Shane Holland responds:
    Posted: April 20th, 2007 at 8:47 pm

    If so, some of those I needed in there, but am working on cleaning the majority (if not all), up.

  20. Gill responds:
    Posted: April 23rd, 2007 at 8:14 am

    Following on from PayPal buttons, have you seen the new Google Checkout code?

      £2.95 - Magazine Back Issue 59
      £2.95 - Magazine Back Issue 58
      £2.95 - Magazine Back Issue 57

    and no, I haven’t made those values up. At least with Paypal you can generate one set of code then replicate it in your editor just by changing some details but this! you have to do it via their generator.

  21. Gill responds:
    Posted: April 23rd, 2007 at 8:16 am

    Errr, Mike can you edit that? It was supposed to show the code not display the results.

  22. Gill responds:
    Posted: April 23rd, 2007 at 8:53 am

    On its way

  23. Gill responds:
    Posted: April 23rd, 2007 at 10:41 am

    You’re a likkle star. :-)

  24. Gill responds:
    Posted: April 23rd, 2007 at 11:54 am

    Ahh but as you changed it, does it now “correct work” ;-)

  25. Tom Barta responds:
    Posted: May 19th, 2007 at 4:47 am

    Mike, I appreciate your sentiment, but I think your wrath goes too far. You’re complaining about web authors not adhering to standards… yet in HTML 4.01 Strict, the OPTION close-tag is not required. Thus, the PayPal authors were likely to have been correct in adhering to standards that are different from yours. You can’t fault them for that, unless by “standards” you really mean “my standards”. The same goes for mixed case elements and attributes (btw, you’re confusing CamelCase with sTuPiDcAsE… it is a disservice to describe camel-cased text as stupidly). If you really have a problem with looking at someone else’s valid SGML markup, run it through HTML Tidy with XHTML ouput.

    You seem to like validation just for the sake of validation, which essentially amounts to a religious belief. If you really want to sell web authors on this stuff, you need to provide them with tangible motivation to do so. Some benefits off the top of my head (sorry if this doesn’t format well):

    1) Validation reduces the impact of obvious typos the same way a C++ compiler will catch a missing semicolon, catching faults before they become errors.

    2) Variance in web browser display is reduced for valid markup, reducing cross-browser-compatibility expenses.

    3) Markup modifications are less likely to contain faults due to invalid markup (see 1), shortening the development cycle for any markup modification.

    4) Valid XHTML markup is required to serve Content-Type application/xhtml+xml. This means that validation is required for anyone wishing to serve up inline SVG.

    5) Valid XHTML markup opens up many possibilities for repurposing data. An XSL transformation could be applied XHTML to produce, for example, LaTeX formulas out of MathML, or to detect and extract microformat content.

    Some drawbacks come with that, of course…

    1) The learning curve for web authoring is steeper, particularly if you use application/xhtml+xml (Firefox’s yellow screen of death).

    2) External ad content, which is rather important for many free sites on the www, may be malformed

    3) user-generated content may be malformed, particularly legacy data

    4) Running HTML Tidy on all sources of external content (2,3) can be a real CPU killer for busy sites

    5) Strict validation of attributes in XHTML may prevent the use of some microformats (HTML 4.01 strict allows arbitrary additional attributes per spec)

    6) Updating any large legacy codebase (markupbase?) can be very expensive and produce unexpected errors

    7) XHTML 1.0 has to be treated somewhat specially: If it is not served up as application/xhtml+xml it is no different from HTML 4.01 strict. However, IE (and probably others) cannot properly render it when served with the correct mimetype. Serving XHTML as text/html is in every way I have discovered no more useful than serving “nice” (e.g. XHTML-compatible except for self-closing tags) HTML 4.01 strict.

    Anyone weighing the options should decide for themself which standard to follow. You clearly have chosen XHTML, but I’m not sure about all of your motives… some of them would be completely resolved with a little bit of HTML Tidy and some vi/emacs/IDE-of-choice regexp fu. Personally, the real reasons I go with XHTML for any project are 1) inline SVG is incredible, 2) enforcing yellow-screen-of-death for an entire project reduces defects by the less-competant developers… a lot. Other than those cases, I use HTML 4.01 strict/nice.

  26. Tom Barta responds:
    Posted: May 21st, 2007 at 5:17 pm

    Regarding CamelCase or sTuPiDcAsE, it’s doesn’t really matter, I still think it’s better if they stick to a more universal lowercase in their mark-up.

    Sorry, I didn’t mean to imply that mixed-case at all is good for SGML markup of any kind. I just wanted to defend what I saw to be an affront on camel-casing in general.

    My use of XHTML (even though it’s being served as text/html) is mostly because I work with WordPress so much and to me flip-flopping back and forth is harder. I have absolutely nothing against HTML 4.01

    Understandable. I probably would too, were I working with WP. I find there are a lot of misinformed web developers who seem to think that HTML 4.01 = Awful, so I bring it up probably more than I should in conversation.

    I think if people are going to have web sites they should try their best to make and maintain good sites that are as compliant with (web, not my) standards as possible.

    Ok, but some of the things you bring up in your rant are still standards-compliant; they’re just following older standards than they probably should be. I suppose my original point could be better summarized as “If you are going to be picky, be loud about being picky, instead of hiding behind standards-compliance.” Future-proof HTML 4 is stricter than any of the existing HTML standards, and it’s a good practice for anyone to follow, but it is above and beyond existing validatable standards.

    One action of the provider’s end, affects many people so they could do a whole lot better. And when asked for support, they should provide the right information, not some BS like you can’t close the options.

    I agree that misinformation spread by a markup provider is awful (and awfully stupid). Funny thing is, if even 5 people bug them about the markup, the support costs have probably already outweighed the development cost of fixing the problem in the first place, so it’s in their best interest even from a “greedy corporation” perspective to release something clean.

  27. The Reality of Dealing with a Mule - responds:
    Posted: June 5th, 2007 at 12:47 am

    […] I’ve discussed the poor quality of free code and applications before. Since very few people had helped me spread the word as I had hoped for, I’m at it again. I realize it isn’t going to be easy to get the core of the development community to change, but I’m no quitter. […]

Sorry. Comments are closed.

Note: This is the end of the usable page. The image(s) below are preloaded for performance only.