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.

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.

Filed under Wicked Wild Web, Coding & Markup —

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

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!
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.
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.
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.
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.
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.
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 […]
Mike Cherim responds:
Posted: April 14th, 2007 at 12:47 am →

I wish spring would hurry up and get here weather-wise, so everyone would stop with the cranky ranting.— Ty

Indeed. This is how my spring seems to be going.

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

I hear you. Me too.

You have to be kidding me! You think I’m going to stick that load of garbage in my nice clean page? — Gill

Lol. Exactly.

What I don’t get is this: If these providers offered valid and accessible markup, those who are ignorant to web standards shouldn’t be at all put off or inconvenienced by it. Meanwhile, to those who do know life on Standards Row would really benefit! In fact, “benefit” would be derived from this by all parties.

Meme this! If hundreds or even thousands of writers blog this topic we could actually see some change. It’s not like I’m asking a lot — really.
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.
Mike Cherim responds:
Posted: April 16th, 2007 at 2:06 am →

True, it’s still text/html, but I was sort of thinking WordPress web logs (which offer an XHTML Transitional DocType out of the box). A lot of them are invalid because of these add-ons, regardless of how the XHTML markup is served. I like seeing that green “Valid” bar
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.
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!
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. […]
Mike Cherim responds:
Posted: April 17th, 2007 at 1:30 pm →

@Alex: I think we do agree completely. To word my original sentiment differently (maybe I wasn’t clear in the words I used): If the plugin or add-on is producing data that should be organized and displayed in a table then it’s proper and of value to the end-user (”doing the users a service”). But if it’s not, it said output is distributed with table markup for the purpose of layout — like that PayPal form — then they should find another means of displaying the output in question (”find another way”).
Alex responds:
Posted: April 17th, 2007 at 2:06 pm →

Sweet, thanks for the clarification Mike!
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.
How to make any web page print nicely in Opera - MeganMcDermott.com 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! […]
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
Terry McNeese responds:
Posted: April 18th, 2007 at 8:57 am →

Aaaargh!
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.
Mike Cherim responds:
Posted: April 18th, 2007 at 8:58 am →

@Sparky: Very good point! I should have been more clear about case. I tend to only write XHTML mark-up because I work with WordPress such much that I use it on non-WordPress projects as well and for me it’s easier to stick with one or the other. But you are certainly correct, and I agree that writing lowercase and closing tags makes the site more future-compatible if switching to XHTML at some point (and it’d be better if the “providers” used a consistent style — overly well-formed HTML or valid XHTML). Writing this makes me wonder: Will lowercase markup and closed tags be a requirement in HTML5 (I sort of hope so)?
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 WordPress.org - assuming I’ll have more control over everything?

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

Take care.
Mike Cherim responds:
Posted: April 20th, 2007 at 11:17 am →

I think you’ll like WordPress Shane. A lot depends on the template, but if integrating it really involves not much more than placing a few function calls and “the loop” into an existing page template of your making. Thus you have almost 100% control over the output. And many of the aspects that one would be tempted to get into the core file to change (not advisable), can still be manipulated in the theme files by adding parameters into the aforementioned function calls. I’m using WP for the back-end of most sites I now do… it just makes a lot of sense to do so on many levels.

On another note, your site is on the chopping block over at Accessites right now — expect to hear from us next week — and we noted those clearing divs. We wondered what those were all about.
Shane Holland responds:
Posted: April 20th, 2007 at 8:44 pm →

Are you referring to the div class="clear"?
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.
Mike Cherim responds:
Posted: April 20th, 2007 at 8:58 pm →

Yes, ’twas a class not a style. My bad.
Gill responds:
Posted: April 23rd, 2007 at 8:14 am →

Following on from PayPal buttons, have you seen the new Google Checkout code?
:-0
```
  £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.
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.
Mike Cherim responds:
Posted: April 23rd, 2007 at 8:32 am →

You’re going to have to send me the code by regular email Gill since whatever you put in was stripped out I think.
Gill responds:
Posted: April 23rd, 2007 at 8:53 am →

On its way

Mike Cherim responds:
Posted: April 23rd, 2007 at 9:16 am →

Here you go, Gill.

<form
action="https://checkout.google.com/cws/v2/Merchant/9999999999999999/checkout"
id="BB_BuyButtonForm" method="post" name="BB_BuyButtonForm">
    <table cellpadding="5" cellspacing="0" width="1%">
        <tr>
            <td align="right" width="1%">
                <select name="buyButtonCart">
                    <option
value="PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCjxjaGVja291dC1zaG9wcGluZy1jYXJ0IHhtbG5zPSJodHRwOi8vY2hlY2tvdXQuZ29vZ2xlLmNvbS9zY2hlbWEvMiI+DQogIDxzaG9wcGluZy1jYXJ0Pg0KICAgIDxpdGVtcz4NCiAgICAgIDxpdGVtPg0KICAgICAgICA8cXVhbnRpdHk+MTwvcXVhbnRpdHk+DQogICAgICAgIDx1bml0LXByaWNlIGN1cnJlbmN5PSJHQlAiPjIuOTU8L3VuaXQtcHJpY2U+DQogICAgICAgIDxpdGVtLW5hbWU+VGhlIEJlYXQgTWFnYXppbmUgQmFjayBJc3N1ZSA1OTwvaXRlbS1uYW1lPg0KICAgICAgICA8aXRlbS1kZXNjcmlwdGlvbj5CYWNrIGlzc3VlcyBmb3IgVUsgZGVsaXZlcnk8L2l0ZW0tZGVzY3JpcHRpb24+DQogICAgICA8L2l0ZW0+DQogICAgPC9pdGVtcz4NCiAgPC9zaG9wcGluZy1jYXJ0Pg0KICA8Y2hlY2tvdXQtZmxvdy1zdXBwb3J0Pg0KICAgIDxtZXJjaGFudC1jaGVja291dC1mbG93LXN1cHBvcnQgLz4NCiAgPC9jaGVja291dC1mbG93LXN1cHBvcnQ+DQo8L2NoZWNrb3V0LXNob3BwaW5nLWNhcnQ+DQoNCg==//separator//zzXTnUKKkh+nQYXLTp3iaN95xf0=">£2.95
- Magazine Back Issue 59</option>
                    <option
value="PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCjxjaGVja291dC1zaG9wcGluZy1jYXJ0IHhtbG5zPSJodHRwOi8vY2hlY2tvdXQuZ29vZ2xlLmNvbS9zY2hlbWEvMiI+DQogIDxzaG9wcGluZy1jYXJ0Pg0KICAgIDxpdGVtcz4NCiAgICAgIDxpdGVtPg0KICAgICAgICA8cXVhbnRpdHk+MTwvcXVhbnRpdHk+DQogICAgICAgIDx1bml0LXByaWNlIGN1cnJlbmN5PSJHQlAiPjIuOTU8L3VuaXQtcHJpY2U+DQogICAgICAgIDxpdGVtLW5hbWU+VGhlIEJlYXQgTWFnYXppbmUgQmFjayBJc3N1ZSA1ODwvaXRlbS1uYW1lPg0KICAgICAgICA8aXRlbS1kZXNjcmlwdGlvbiAvPg0KICAgICAgPC9pdGVtPg0KICAgIDwvaXRlbXM+DQogIDwvc2hvcHBpbmctY2FydD4NCiAgPGNoZWNrb3V0LWZsb3ctc3VwcG9ydD4NCiAgICA8bWVyY2hhbnQtY2hlY2tvdXQtZmxvdy1zdXBwb3J0IC8+DQogIDwvY2hlY2tvdXQtZmxvdy1zdXBwb3J0Pg0KPC9jaGVja291dC1zaG9wcGluZy1jYXJ0Pg0KDQo=//separator//pgvnpeP8H2twtvIGznntjZtI9eA=">£2.95
- Magazine Back Issue 58</option>
                    <option
value="PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCjxjaGVja291dC1zaG9wcGluZy1jYXJ0IHhtbG5zPSJodHRwOi8vY2hlY2tvdXQuZ29vZ2xlLmNvbS9zY2hlbWEvMiI+DQogIDxzaG9wcGluZy1jYXJ0Pg0KICAgIDxpdGVtcz4NCiAgICAgIDxpdGVtPg0KICAgICAgICA8cXVhbnRpdHk+MTwvcXVhbnRpdHk+DQogICAgICAgIDx1bml0LXByaWNlIGN1cnJlbmN5PSJHQlAiPjIuOTU8L3VuaXQtcHJpY2U+DQogICAgICAgIDxpdGVtLW5hbWU+VGhlIEJlYXQgTWFnYXppbmUgQmFjayBJc3N1ZSA1NzwvaXRlbS1uYW1lPg0KICAgICAgICA8aXRlbS1kZXNjcmlwdGlvbiAvPg0KICAgICAgPC9pdGVtPg0KICAgIDwvaXRlbXM+DQogIDwvc2hvcHBpbmctY2FydD4NCiAgPGNoZWNrb3V0LWZsb3ctc3VwcG9ydD4NCiAgICA8bWVyY2hhbnQtY2hlY2tvdXQtZmxvdy1zdXBwb3J0IC8+DQogIDwvY2hlY2tvdXQtZmxvdy1zdXBwb3J0Pg0KPC9jaGVja291dC1zaG9wcGluZy1jYXJ0Pg0KDQo=//separator//iTDLlX1OGd2wT9M+TGjAFdZD01M=">£2.95
- Magazine Back Issue 57</option>
                </select>
            </td>
            <td align="left" width="1%">
                <input alt=""
src="https://checkout.google.com/buttons/buy.gif?merchant_id=99999999999999999&amp;w=117&h=48&amp;style=white&amp;variant=text&amp;loc=en_US"
type="image"/>
            </td>
        </tr>
    </table>
</form>

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

You’re a likkle star.
Mike Cherim responds:
Posted: April 23rd, 2007 at 11:22 am →

I just added one of those 80×15 page rank icons to my sidebar. The site I got it from offered the following XHTML-ready (not marked as such) mark-up:
```
 <a href="http://www.prchecker.info/" target="_blank">
 <img src="http://www.prchecker.info/PR3_img.gif" alt="Check PageRank" border="0" /></a>
```
And it should be like this to be valid and proper on many sites (especially since it’s XHTML):
```
 <a href="http://www.prchecker.info/">
 <img src="http://www.prchecker.info/PR3_img.gif" alt="Check PageRank" width="80" height="15" /></a>
```
Pretty typical and a good example of what I’m talking about. To make matters worse, the following notice was posted for users of this code:

IMPORTANT: Please DO NOT modify the code, otherwise we can not guarantee the correct work of our free page rank checking tool that displays the page rank value!

In light of seeing a warning like this, it should would be nice if the code was correctly offered
Gill responds:
Posted: April 23rd, 2007 at 11:54 am →

Ahh but as you changed it, does it now “correct work”
Mike Cherim responds:
Posted: April 23rd, 2007 at 12:11 pm →

Lol, “correct work” indeed it does.
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.
Mike Cherim responds:
Posted: May 19th, 2007 at 11:36 am →

[…] yet in HTML 4.01 Strict, the OPTION close-tag is not required.

I’m fully and completely aware of that, Tom. But it doesn’t seem PayPal understands that in XHTML they are required (and not a bad practice in HTML either). If they closed the options it’d that much more universal. Instead the support staff over there said they had to remain open. That’s just not the case. I think they should offer it in both ways if they can’t provide it one way that is valid with all DTDs.

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. Remember, authors are producing something that will be used on many web site so they should try to ensure their practices are allowed on as many of those web sites as possible.

Regarding the advantages and disadvantages of validation, you’re absolutely right, that wasn’t really what the article is about but you provided some good reasons in your comment. Excellent list actually. Thanks.

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 (as long as it’s strict… I think everyone should produce validly strict markup since anything less doesn’t seen necessary in my mind).

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. Same would apply if we were talking about cars or furniture.

My complaint, and the point of this article, is that providers of code should try to offer quality, universally-valid mark-up when and where possible. Many people don’t know so I feel they have a responsibility to passively support as many users as possible by producing quality code. This would mean offering mark-up that is valid in more situations or by offering mark-up in different flavors, using semantic elements for the right purposes and not include (sometimes invalid) presentational attributes where they shouldn’t be. And they should be concerned with accessibility. 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.
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.
Mike Cherim responds:
Posted: May 21st, 2007 at 6:12 pm →

I’m certainly not opposed to CamelCase. Classes, IDs, text… it’s all good. And CamelCase, I’ve learned, has some value for screen reader users in that the reader will speak text CamelCase as separate words. Example: Web site, written as website is spoken as “websitah” whereas WebSite is spoken properly.

Regarding my rant about closing tags, I guess I should have been more clear about that in the article. I prefer distributed code to have closing tags so it works with all the DTDs, not just the one they’re writing too (assuming they are writing to a specific DTD). The thing that got my goat, so to speak, was that PayPal told my client the issue was my fault because I closed the tags. Not only was it inaccurate information, it made me look bad in the client’s eyes. I had to explain myself. Regardless, your point is well taken.

Thanks Tom!
The Reality of Dealing with a Mule - Beast-Blog.com 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.

Beast-Blog.com
Stop Writing Garbage Code, Please