It's OK To Break Standards
I tend to be more of a Realist than Purist when it comes to debating semantics, web standards, progressive enhancement, and all the other topics web developers are talking about in order to educate and inform their audience. I’m an advocate for all of these things, but that doesn’t change the fact that you shouldn’t bend them or break them if the situation calls for it.
Am I saying we should go back to table-based layouts? No. Do I think we should use proprietary tags in our markup? No. Do I think font tags should be reinstated? No. Do I think alt attributes on img tags are a waste of time? No. I think we have to be smart about the decisions we make as web developers and not blinded by the false promise, that no matter what the case, standards are always the right answer. Our decisions have to be made in context to the constraints we’re faced with.
Innovation isn’t the ability to follow a set of standards, it’s the ability to bring something new to the table. Technology doesn’t advance by simply following rules and guidelines; if that were the case we’d still be reading stone walls with a lit torch. Innovation demands that we break rules, however that doesn’t mean we shouldn’t make educated decisions.
Kathy Sierra recently published a great article entitled “F*** the rules!” where she talked about rules inhibiting innovation:
A huge chunk of the implicit professional rules today are damaging because they inhibit innovation. They stop the one thing businesses need the most–breakthough ideas. –Kathy Sierra
While browsing my feeds the other day, I came across a post by fellow 9Ruler Stuart Colville titled “Don’t use Javascript to hide bad markup”. Here is an excerpt from the article:
In my opinion JavaScript shouldn’t be used as a means to hide bad code from the source. This includes using JavaScript as a way of hiding both invalid or non-semantic markup. In his re-design of Vivabit I think Patrick Griffiths made the right decision in not using JavaScript to add in the extra markup he needed to make his elastic design with all of it’s rounded corners work.
I agree with Stuart in that Javascript shouldn’t be used as a means to hide bad code. The problem here is that the word bad is relative to it’s context and two different people interpret bad differently. I think it’s bad to use Javascript to hide font tags, but why would an educated developer do this? They wouldn’t. Stuart thinks we shouldn’t use Javascript to enhance aesthetics if it hinders with semantics. While I understand his concern, I disagree completely. (Upon further discussion) Stuart thinks we shouldn’t use Javascript if our intent is only to hide non-semantic code from the source.
Most of the time this happens (injecting markup into a document via Javascript) a developer is working around an implementation problem. If developers could semantically and practically achieve a desired aesthetic without the use of Javascript, they would. Rounded corners is just one example, but it’s certainly not the only case in which this applies. We can achieve rounded corners through css and non-semantic markup. The Vivabit rounded corners implementation is not semantic:
<li><span><span><span>Amnesty</span></span></span></li>
Is this not just as much a fix as using Javascript? The span tag has no semantic meaning. While I don’t think the markup is bad in context to the problem he was faced with, I just don’t think it’s any better than an elegant bit of Javascript. I think Patrick did what he had to do in order to fix the problem he was faced with. He could’ve used Javascript to inject the span tags in as well. It doesn’t make it any more right by using redundant span tags in the HTML source.
One could argue that those without Javascript wouldn’t be able to view the rounded corners. One could also argue that if you were browsing with a text-only browser you wouldn’t be able to see them either. Javascript always seems to take the cake as the least elegant solution when HTML and CSS can do the job. This is a blind assumption. Javascript is not the devil’s play thing and CSS and HTML are not always the answer. ECMA Script (Javascript) is a standard as well.
If we are so adamant about standards, why do we support non-standars every day. We use applications like Gmail, Backpack, del.icio.us, flickr–all of which break the rules. If you were pro-life, you wouldn’t gas-up the ride so your sister could make a trip to the clinic would you?
Take a look at Ma.gnolia.com–The social bookmarking website designed by some of the most widely recognized industry heavy weights when it comes to standards and the web. Just a quick browse through the source on the home page got me this:
<img alt="Clear" height="1" src="/images/clear.gif" width="3" />
If you disable styles you’ll also see that there is also some empty list items. The point here is that cookie-cutters (standards) don’t always work when your facing real problems in a real working environment.
Standards and semantics are an essential part of the web, but we need to make smart decisions, not blind ones, when it comes to when, where, and how to apply and break them.
Sorry, comments are closed for this article.
Justin develops iPhone and Mac software over at Labrat Revenge by night and by day he is the Design Director for entp, the company behind Lighthouse, Warehouse, and Mephisto. You can check out his dated portfolio for a peek of what he's done.
-
Beautifully simple issue tracking and project management. With a beautiful Mac-like interface, email and subversion integration, Lighthouse is the perfect project management tool. We took the suck out of issue tracking.
-
Jan12
YouTube has just announced HouseHub and Senate Hub.
permalink -
Oct10
Best Practices For Cocoa and CocoaTouch—Invaluable tips from Cocoa developers.
permalink -
Sep25
Track House And Senate Votes On Twitter. I’ve put together a small script that parses vote data collected by Govtrack.us and posts to twitter.
permalink -
Jul28permalink
Protip: Color grep searches in terminal
alias grep='GREP_COLOR="1;37;41" LANG=C grep --color=auto'Stash this away in your Z Shell (~/.zshenv) or Bash environment (~/.bashrc) and set your preferred ANSI code.
-
Jun08
ActiveRecord Ported To Objective-C brought to us by Ninja Kitten
permalink -
May06
With the release of Opera’s DragonFly, IE 8’s Developer tools, Safari’s/Webkit’s Web Inspector and Drosera; and the Grand Daddy of them all, Firebug – we’ve now come full circle.
permalink -
Feb08permalink
DoubleClick and Define using Apple Dictionary
var selection; if(window.getSelection) selection = window.getSelection(); else if(document.selection) selection = document.selection.createRange(); document.observe("dblclick", function() { if(navigator.userAgent.include("Macintosh")) { location.href = "dict://" + selection; } });A quick (and probably dirty) Prototype-based hack allowing Mac users to get the definition of any word by double clicking it.
-
Feb08permalink
Object.extend(Date.prototype, { strftime: function(format) { var day = this.getUTCDay(), month = this.getUTCMonth(); var hours = this.getUTCHours(), minutes = this.getUTCMinutes(); function pad(num) { return num.toPaddedString(2); }; return format.gsub(/\%([aAbBcdDHiImMpSwyY])/, function(part) { switch(part[1]) { case 'a': return $w("Sun Mon Tue Wed Thu Fri Sat")[day]; break; case 'A': return $w("Sunday Monday Tuesday Wednesday Thursday Friday Saturday")[day]; break; case 'b': return $w("Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec")[month]; break; case 'B': return $w("January February March April May June July August September October November December")[month]; break; case 'c': return this.toString(); break; case 'd': return this.getUTCDate(); break; case 'D': return pad(this.getUTCDate()); break; case 'H': return pad(hours); break; case 'i': return (hours === 12 || hours === 0) ? 12 : (hours + 12) % 12; break; case 'I': return pad((hours === 12 || hours === 0) ? 12 : (hours + 12) % 12); break; case 'm': return pad(month + 1); break; case 'M': return pad(minutes); break; case 'p': return hours > 11 ? 'PM' : 'AM'; break; case 'S': return pad(this.getUTCSeconds()); break; case 'w': return day; break; case 'y': return pad(this.getUTCFullYear() % 100); break; case 'Y': return this.getUTCFullYear().toString(); break; } }.bind(this)); } });UPDATE: Bugs fixed. Thanks Andrew and Stephen
Also, some of my old and new code has been posted on GitHub. You might find something useful.
-
Feb04
A beautiful, organic animation by Flight404 created using Processing.
-
Jan08
Aaron Patterson shows us how to define ruby methods which can be called from JavaScript using RKelly.
permalink -
Jan07
Dustin might not surprise you at your house with a book in hand, but he’ll damn sure send you his innermost fu in the form of a shiny yellow and black book. It’s an excellent read if you’re looking to put more funk in your functions and class in your classes. Check out “Pro JavaScript Design Patterns” by Dustin and Ross Harmes.
—I’m Justin Palmer and I approve this message.
permalink -
Dec23
IE 8 PAsses the Acid 2 Test for those not keeping tabs on things.
permalink -
Oct24
Mislav has written up an excellent overview on upgrading Radiant (which used 1.5) to Prototype 1.6. The article does a great job of showing how 1.6 is superior to 1.5.
permalink -
Oct19
According to the New York Times, the Daily Show Archives, with over 7,000 videos are online—free and searchable.
permalink -
Oct11
Copyright © 2005-2009 Justin Palmer | Powered by Mephisto
Discussion
I’m a standards whore, if I can’t do it with standards I’m not gonna do it. Although I guess you’re right, it won’t allways work in the professional world. But—at the very least—I think one should try to keep it as accessible as possible, something that can be hard without following the standards.
Oh, and by the way: Ma.gnolia (Your dot is in the wrong place.)
I very much agree with you – the cookie-cutters are great to keep people from creating non-accessible, and non-semantic code..
The problem is that, in my experience, you sometimes end up creating less accessible code, in order to squeeze it through that goddamn W3-machine from hell, called the validator…
Please don’t get me wrong, and I don’t suppose you will, the W3C is doing a great job, and we need standards around the web, so that we don’t end up with another era of IE-specific sites et cetera…
But the priority should always be:See how validation ended up at the bottom of the list? I tend to use Apple as an inspiration… It should look good, and just work…
I partially agree with you. We should use the right tool to each job. This means that if something is impossible to be done with standards, non-standard stuff should be used.
However, in your javascript vs. spans example, I disagree with you. Adding round corners by supplying extra markup is a bad thing. In a site redesign you would have to change the markup (and that can be a medium to big sized task), instead of just commenting one line of javascript to disable the effect. Markup should be semantic.
Just my 2 cents.
@jon: Thanks for catching that!
@John: Great list. I think cross-browser compatibility is a subset of accessibility. I use validation as a way to debug my code if I run into any problems, but I never use it to determine if what I’m working on is 100% compliant.
@Rui: You make a great point. I always end up starting from scratch when redesigning, but in a realign your comments ring true. Even to disable the effects you have to comment/remove more than one line of CSS compared to a single function call in Javascript.
bq.I think Patrick did what he had to do in order to fix the problem he was faced with. He could’ve used Javascript to inject the span tags in as well. It doesn’t make it any more right by using redundant span tags in the HTML source.
In my post I wasn’t wholly justifying the implementation of Patrick’s design, that’s another argument. You are absolutely right, the use of spans on vivabit.co.uk is far from semantic. However, the decision to not use JavaScript to hide this from view was a sound one because in this case what would using JavaScript have achieved apart from “obscuring” the actual markup used?
I think you miss the point. Adding all those non-semantic spans to the code makes the document more bloated with non-relevant code and therefore each word in the content less relevant. Of course this is permisible if this tricks are used sparsely or SEO is not a priority, but the reasons for clean code are not just elegance and purism but very functional too. In most cases it’s not about beeing a purist but improving SEO. If your site needs a lot of tricky design then yes, you should consider javascript to minimize your code and improve your code to search engines.
Hey Stuart, thanks for taking the time to respond.
I agree that if the sole reason for using Javascript merely as a means to hide the span tags, then indeed thats wrong case for Javascript and is no better than placing them in the markup.
It is better (sometimes) because it reduces HTML. Search engines read your HTML, not your JS.
I think John (with the “h”) nailed it. Regardless of the aspects of one specific implementation, the old adage that “rules are there to be broken” holds true regardless of the rule.
If we all played by the rules how would we advance?
I am totally with you on the conclusion. In a working environment when lots of elements involved in coding other than standard/semantic/accessible codes- integration with legacy codes- the smart choice is when, where, and how to apply and break the rules.
Regarding rounded corners with css or javascript. Per definition css should be used for style/design while javascript is for functions, I think rounded corners are in style/design categories, so adding non semantic codes for design is better to doing design with javascript.
“Rules may be broken once understood” might be more appropriate. If nobody played by rules how would we advance?
Ignoring rules at one level may inhibit the options available at an another level. For example, writing a HTML parser is not. fun. at. all. and this increases the cost (not necessarily in terms of money) of creating innovative applications that consume HTML. Open source helps here, but there are limitations to that model too.
As an another example, consider the Google Web Accelerator fiasco, where widespread ignorance of HTTP lead to getting good technology suspended until further notice.
It honestly took me a while to realize which side of the fence you are trying to argue. I think the first paragraph sets us up for a confusing read:
”...but that doesn’t change the fact that you shouldn’t bend them or break them if the situation calls for it.”
Not only does that contradict your other points, but it’s not a fact.
It’s a fact that you can bend them or break them.
Andrew, I can see where that would be confusing. I’ll blame it on my poor writing skills. :-)
I am a proponent for breaking them when you need too. That should be fairly clear by the end of the article.
Maybe this isn’t the proper forum (feel free to delete), but your preview mechanism is not accurate (which negates the entire purpose?)
When I copy and paste the word “shouldn’t” from your entry, it looks fine in the preview.
Definitely, a topic in need of a lot of discussion because it seems there are a lot of confused developers out there.
As I see it, the ‘real’ world exists as a big test machine for the standards and techniques that bodies such as the w3c create, hence the concept of versioning everything from an application build the web itself!
Standards = language = semantics.. It is merely a bunch of rules that the makers of user agents need in order interpret the code of millions of developers to the best of their ability, who themselves have their own styles and techniques in using these standards. Whichever way we look at it, standards bodies, user agent makers and developers will always be separate entities and have their own agendas and will always have a seesawing relationship.
You say tomato but, f**k it, I’m calling it an apple. If I can make you (my audience) understand which fruit I’m talking about, then I have been successful, regardless of whether the grammar checker in my word processor understands.
The problem (obsession) that the recent popularity of ‘standards’ has created is the grand sense of absolutism by, dare I say it, fascist developers. Our job as developers is not to adhere to standards. Our job as developers is to act as the oil in the machine created by standards bodies and user agents. Our job as developers is to use, abuse and hack those standards to maximise the availability of our (clients?) intention, e.g. the website, to the benefit of the user. It’s a pretty simple equation – does [Application App1] work in [Browser B1, Browser B2, ScreenReader S1, etc..] under [Condition C1, Condition C2, Condition C3, etc..] for [Audience Au1, etc..]. If so, our job is done.
Or should we just use a validator to avoid our responsibility to test our work properly while waving the flag of standards?
Sorry, I don’t think so. Sure, Innovation is not breaking the rules, but bringing some new ones, some rightest ones.
But in the other hand, it’s not that wize to break rules just to make things look nicer. Why that concern about semantic, you could ask. Well, in the present times, we use, IMHO, a very premitive web —we use our hands and eyes.
But in the future, I bet that bots and agents will do a lot of stuff for us, to enhance the taste and the experience.
That’s why semantic matters. We, I humbly think, have the responsability to give to our children and future generations a good base to use and not just because we haven’t the time to get the job done in the deadlines, make quick decesions and produce unusable things. I mean future unusable things.
We, all are very very despointed by the tables-design (aren’t we?) isn’t that done in the past for design and a make-em-say-wow effect?
That’s why I do think humbly, that we have to seperate the markup from the style at least for these reasons:
Thanks and sorry for my poor english —it’s the 4th language I learned :)