GET OVER IT! 6 Things Web Developers Need to Get Over
One of the downsides of being around developers of varying skill levels, from noob to Open Source legend, is that everyone has an opinion...and they're all wrong. Every one of them. Of course, me being a developer, I'm wrong too. There are a few things, however, that I hear frequently and want nothing more than to scream. Listen here developers: get over it.
Get Over It! Valid Mark Isn't THAT Important!
I'm not saying that it's OK to not close elements, not properly quote attributes, etc. What I am saying is that effectiveness is much more important than picture perfect markup. HTML Validator: go to hell. There's absolutely nothing wrong with using custom attributes. Dojo uses custom attributes within the Dijit library so that developers can create widgets directly from HTML. And you know what? It's fast, convenient, and allows the developer to move on with their lives. Get over it.
Look at Google, a company that employs some of the most intelligent developers in the world. At publish time, Google's homepage has 37 markup errors and 3 warnings. I detailed markup errors on popular websites a while back. They all work perfectly. And have for a while. And will for a while. Get over it.
Get Over It! CSS Hacks are OK!
Of course CSS hacks aren't ideal. Of course we'd like browser support to be consistent. Well, it isn't, so we as developers can only react to the browser vendors' differences. And sometimes a CSS hack is the best (or only) way to do it. I personally choose to add my IE6, IE7, etc. hacks within my main stylesheet instead of conditional statements. Why? Because I want to cut down on requests and when I think of editing CSS, I don't want to be jumping from stylesheet to style to find something. Get over it.
Get Over It! Open Source Projects Owe You NOTHING!
It wasn't until I joined the MooTools (ftw) team that I realized how entitled people who use a given library (JavaScript, PHP, etc.) or open source project feel. Even I was THAT GUY for a while. Want your opinion to matter? Want a feature added to the given library? Want a method within the library modified? There's an easy way to do it: do it. Take the time to code it and donate it to the library. Otherwise hear this: you are owed NOTHING. Zero. Nil. Thousands of hours of other people's time created the toolkit; pitch in and stop whining. Get over it.
Get Over It! Your Opinion Is (Almost) WORTHLESS!
Sometimes open source projects can become the equivalent to the WWE. Everyone's got a strong opinion and everyone else is wrong. Egos, egos, egos. I see it in all of the JavaScript libs (jQuery, MooTools, etc.), JS lib haters (comp.lang.javascript), and libs of every language. You know how you make your opinion worth something? Present it professionally and, most importantly, make it work! Code it, test it, and test it again. Realize that your opinion is worthless if you don't make it happen. Get over it.
Get Over It! Your JavaScript Library's 3ms ISN'T Leaps Ahead of My Lib's 4ms
Selector query times are the biggest pissing contests in the history of the web. While query selector times are certainly important, a 1ms difference isn't enough to spout your mouth off about. Save it. That type of difference is important when you're dealing with hundreds of elements...and if that's the case, you may be doing it wrong. Get over it.
Get Over It! Object Prototype Extension is OK!
As a MooTools team member, I get a lot of grief for MooTools' philosophy on extending prototypes of Natives like Array, String, Function, Object, etc. Extending the prototype makes the object (and all instances of the object type) much more powerful and relieves the need to constantly refer to a single namespace and method to do something. If your library of choice doesn't extend prototypes, that fine -- don't bitch about those that do though. Get over it.
There you have it. Mark today as the day you officially got over it. If you're offended by this post, you're exactly the person that I'm trying to target. Take a step back, think about the big picture, and realize it's time to grow up. I did a while ago -- and my development life is much better.
I agree on all items, except the first. Good markup and semantics do matter when developing. In my experience, some MooTools functions, like creating a sortable, will not even work when the page isn’t valid / semanticly correct.
Using correct semantics and creating valid pages isn’t all that hard; it just takes some time to get the hang of it.
hehe… we’ll said. I’m surprised get over IE6 is not on your list, but I definitely understand many clients have visitors that are stuck in time.
Can I just say: Amen! I agreement with you 100%. Eventhough I hate THE CSS hacks. But even those can be avoided sometimes if people with look beyond what they know about CSS and studied more.
Oh and one more thing: Mootools ftw.
@Magbic Aleman: I’ve said “get over it” about IE6 a billion times now. Sick of it. Should be obvious….but probably isn’t.
… your point #4 applies to point #1. Unless your work stays in a little ivory tower of your own making, plan on getting into serious trouble sooner or later. Beyond that, if you don’t stick to standards (or at least strive to stick to them) that mindset can easily creep into other areas.
“Get Over It! CSS Hacks are OK!”
No.. no their not. They are only valid if placed in a IE only style sheet. Otherwise fix your crappy code. These hacks can break other valid browsers.
“Get Over It! Valid Mark Isn’t THAT Important!”
Thats more of a grey area. While agree that it does not matter if a page completely validates but it does make maintenance of a site much easier if its valid, or at least closely valid.
Let me first start by saying I agree you shouldn’t care for any of the points above, they are however nice to have. But you must be flexible on these and many more points – you can get it done, you can get it done right and you can over do it – it’s your choice which way you go.
The first two points will be a sticking point as in the early years (ie: 99-02) of web standards these two points were pushed hard on to people and a lot of these people did not evolve with the web.
Alot of these people also forgot the reason behind web standards – to make life simpler, to write once work everywhere…
@Mark Harwood: and wow is my gravitor icon old :) i’ve not had hair on my head for at least 5 years.
“Present it professionally and, most importantly, make it work! ”
David, you rock. I’m going to print this out, frame it, and hang it around each of my developers necks.
hahaha. love it!
@Patrick: Totally agree. Valid markup lead to less code hacks and more consistency between browsers.
heh, carry on with these Get Over IT’s and you’ll end up woking on the next Internet Exploder version…..
#1 is by FAR the most important.
Sadly, sometimes perfect code will not do what you need. If it works in every browser, why does it really matter if you have a rel on a div, or a block element in an inline element.
Working code is so canon. Validated code is not.
I dont agree with #1
Maybe if you are doing a blog or a espectacular site with a lot of mootools effects its ok, why you care about Valid Mark?.
But when you work on BIG sites created by a team of developers and a team of designers the best is your code be valid and for me looks more pro..
I’m not saying that you can throw crap HTML all over the place — let that be known.
Take Dojo for example. You can create Dijits by adding a dojoType attribute to elements. Validators don’t like that…but it doesn’t break anything and has huge upside.
Thank you for this! I needed this early in the morning. I’m currently redoing our company’s site and have had to use a couple of IE7 hacks. I felt really guilty for it, but I did it. Hearing you say that makes me feel a bit better. :)
Thanks David, it’s nice to read stuff like this from time to time ;)
I’ll give you 3-6 without a fight, but I’d soften both 1 and 2 a little. Valid markup and CSS is important for several reasons, and not least among them is the inevitability both of new user agents, and revisions to existing user agents.
I’m not a validation slave, but I won’t break validation unless I have a good reason, and understand the ramifications of doing it. Non-compliant HTML and CSS may work in every browser you’ve tested today, but will it work in every user agent in use tomorrow? What will happen if the CSS bug your hack relies on today to create an effect is fixed tomorrow, but not the entire browser? Your hack gets filtered out, but the effect you tried to use it to create gets lost. If there’s a compliant way to deliver the same effect, it is *always* to be preferred.
Too many people use “It works” as sufficient reason to write sloppy code. It’s not, as we discovered when businesses had to spend billions to fix sloppy, but working, code during the Y2K scramble. Dilettantes think only about today; professionals keep an eye on the future as well, so they can keep working *new* projects, instead of constantly going back to fix old ones as the world changes.
A note on your first point “Valid Mark Isn’t THAT Important!” there is somewhat a quasi-contradiction in that you also say
“I’m not saying that it’s OK to not close elements, not properly quote attributes, etc. What I am saying is that effectiveness is much more important than picture perfect markup”
I agree on the latter point that markup means balls if the site doesn’t work properly in any respect, but the former of correctly writing markup is defined by valid markup.
Validation is that stepping ground where we agree that the correct way is this rule set (be it transitional, strict, etc.). Everybody is on the same wave-length when it comes to the correct way of writing something rather than one guy thinking “I’ll do it this way” and the other saying “So, that’s wrong do it this way”. It’s consider (or I believe it should be any way) by front-end coders around the world as the “most” correct way of doing something.
It’s not to say that you should NEVER break the rules (iframes in strict XHTML isn’t that uncommon as it’s a safe way of providing external content without security worries in some respects), but when approaching this everybody on the team should be on the same wavelength. People in a background in programming standards within business should catch my drift.
But in my situation I write front-end within a company and as a freelancer. In both respects I may not be the sole coder for the time that site is live/active so by following a set of standards set by a body of people. I can code to that mark and the next person to work with the code knows the format to follow without ever knowing I exist and carry on in the same style without thinking “WTF?”
In all fairness, validation isn’t hard to follow; if you work at a company you should have a set of standards on your front end code that’s more detailed any way that incorporates the W3C set (layout of code as well as uses of code-where, etc). It stops that down time of thinking “should I do it like this or like that?” but also limits the possibilities of code breaking later down the line. If you follow the set of standards the code should, in-theory, work. (I know not the exact case, but it does help a lot in my area where I code from IE6 to the latest nightly of WebKit)
Just because Google does it, doesn’t mean it’s correct. But I may not be correct either, just my opinion on validation in regards to front-end.
What an excellent post! Sometimes, people just need to be told how it is.
Assuming you’re using the HTML5 doctype (who isn’t at this point?), data- prefixed attributes solves the problem of expando attributes failing validation.
I think the main point is strive for perfection (valid code, no css hacks, etc.) but accept the reality of projects in this less than perfect world.
As a heavy js developer I can tell you.
Adding power to the Object prototypes is ok, but modifying the CORE methods IS NOT! (Like what Prototype library does).
If you are developing an isolated app or webpage, its ok, do you own mess, I don’t care, but when you will embed, share, interact with other codes, please please please, don’t poison the DOM nor the Objects.
As a heavy js developer I can tell you.
Adding power to the Object prototypes is ok, but modifying the CORE methods IS NOT! (Like what Prototype library does).
If you are developing an isolated app or webpage, its ok, do you own mess, I don’t care, but when you will embed, share, interact with other codes, please please please, don’t poison the DOM nor the Objects.
Yeah well said. I enjoyed every part of it. Tongue ‘n cheek. But so try. Why is that so many developers choose to argue about the most trivial things, this in sacrificing functionality and productivity.
I once had a boss/senior developer who was so uptight about naming conventions and case, etc that he drove me mad. Concentrated more on that than actually getting the job done.
So who cares if SpaCE is wittten sPaCe or space as long as it works right.
@Cory Mathews: *they’re
Spelling > CSS
Prototyping in JavaScript is good, though does have a bit of an overhead when compared to funneling everything through a centralized object. I, personally, find prototyping to be the way to go. But you should not prototype Object since it will mess up
for(var x in y).And, I’m gonna disagree with your bit about hacks. You can always avoid hacks. Avoid bad markup to avoid having no other option. And use IE conditional comments. I know you said that you don’t want to edit multiple files, but IE included .css files are usually pretty small. And you can easily find any line of css markup from any file (assuming the file is not minified) via firebug.
Oh and for anyone disagreeing with the bit about markup not having to be valid, there are ‘invalid’ ways to write perfectly decent and functional code. Like how in strict link is valid yet link is not.
Running your site through a validity check is good to find tags not properly closed, etc. But these ‘valid’ standards are set up to ensure that a page works. Doesn’t mean it won’t if you don’t follow it to a T.
@Timothy: That second ‘link’ has target=’_blank’. I didn’t realize it’d be parsed to html
Not true! comp.lang.javascript loves My library :P
I’m sure someone pojted that out but I disagree with CSS Hacks are OK!
For me doing things the “right way” is better than saving 2 request in IE.
“Please somebody rewrite the following article:
http://en.wikipedia.org/wiki/MooTools
I don’t like its advertising tone. It must be written more neutral.”
I guess this is an open source winning.
This post reminded me of the “Grinds My Gears” segments in Family Guy. Reading it in a Peter Griffin voice makes it much more enjoyable.
@Timothy The use of target=”_blank” is, to my understanding, to do with putting function in (X)HTML rather than using it as content specific. So the strict way is to say rel=”external”; this means that in a relative sense, the link is an external one (same as using rel=”me” to say that the link is to do with you, like your twitter page). you can then add a javascript to interact with external as you so wish without.
It follow the pattern
– (X)HTML == content and context
– CSS == style and layout
– Javascript == functionality and interaction
Strict standards does try and enforce this layer pattern. There is a method in their madness!
Some could argue that a link tag is a function, but it content specific; so an address or name is context relevant (such as the links to our sites in this very comment reel as the link is content relevant to our names). Also, if strict meant you couldn’t then it would raise mary hell.
Also, it has been said it forces users to do an action they may not wish to do rather than giving them a choice.
Great entry, love it. Looking forward to you nest installment.
Agreed on all points, except….
Augmenting Native prototypes is okay for your own app, but if you expect to distribute that code beyond your domain, then it’s just plain irresponsible.
Even the prototype team agrees with this!
There are other ways to elegance that don’t cause headaches for the rest of the web.
@Blair Winans: Blair U r seems to be a Manager… U got it what u want
Hmm thats what I was wandering why i was not growing?? U see I dont have access
to every part of my Brain.. Now its time to get 0777
Thanks David….
Hahaha! “Open Source Projects Owe You NOTHING!”, so funny yet so true. Thanks David, we need more like these (I know you us nothing).
@David Walsh: im sick of your face
@David how right you’re! The most important thing in any project is to make it work and work real well, trying to measure up to standard even when things are working will only keep you there for ever. Perfection is in heaven!
@Pranav Dave: U r dump :)
David, way to start a flamed discussion. Nice post though..
I basically agree with everything you said, besides the first one. If you’re using a PHP framework like Agavi or Symfony and want to use filters, say for instance their Form Population Filters, markup is required to be valid, otherwise it breaks. And this is just one example.. Invalid markup isn’t good practice at all, and if it meant I couldn’t use Dijits, then so be it. Valid markup is paramount in any of todays web applications. Come HTML5, this all changes a lot for a lot of us..
What’s interesting though, is writing valid markup and CSS is so easy when you get into the habit of doing so on each and every project, I am always surprised that so many good developers fail to.
@Paul Irish: I want to say Prototype is going to stop extending Element prototypes — *not* stop extending Strings, Arrays, etc. I could be wrong though.
Needless to say, we’ll agree to disagree with extending natives, although I think that saying it’s irresponsible is over the top.
@Dave Ward:
Ermmm … most people?
Why does the cartoon version of you look much cooler than you actually look ;)
Good article but I don’t agree with first two points, becouse:
1. some of our clients checks websites with HTML Validator and they require to be valid ;)
2. there is good library know as CSS Browser Selector (http://rafael.adm.br/css_browser_selector/) and you don’t need hacks and you can put your styles in one file :)
I am going to frame this for everyone to view and absorb it! Excellent post.
Point #6 is controversial. While it may be true for your own project, just understand that you’re effectively turning a library into a framework. If you use more than one of them together, they could not work at all.
CSS hacks: For non-commercial projects, I actively break IE with standardsconformance. Favourite is deploying the project homepage in XHTML to get rid of Windows noob users.
Valid markup: Sometimes valid markup doesn’t even make sense. See ul/li-nesting, quite silly. But anyway if I have a feeling-very-professional-day, valid markup is my only goal. For some projects however, overly invalid markup might screw up jQuery. But then, there are tools to automatically fix it (HTMLPurify), so why waste time on minutiae?
You should do one of these lists for user experience architects.
As developers, we all know that they’re the ones who will get sand in their vaginas when their ‘recommendations’ are overruled by usually more knowledgeable devs.
But…
Valid code and markup is very important. Bad code is just sloppy and unprofessional. Do it right!
CSS Hacks are a cheap cop out. If you’re going to do something – do it right! it will take you longer to search out and put in hacks than it will do to create a separate conditional stylesheet for IE
Anyone’s opinion in any business is worthless if you A: cant do the job (all mouth no trousers) and B: aren’t professional in your manner and C: put up a good fight when you are challenged.
Cos we all are. regularly. usually by non technical business people who naturally know better because they saw a cool demonstration from a man from Adobe about how flash is the future of the web… (we’ve all been there im sure haha)
I applaud you for not putting IE6 in the list :)
I agree with the whole list.
Number 1 on your list is something I really need to “get over”. I spend far to long perfecting code (not just HTML) that in most cases make little or no difference to the finished product.
When I released my first open source project I was really taken aback by the expectations and complaints people made. I’ve made something freely available that could save them countless hours and yet they complain that they have to invoke two methods rather than one like some other app that they didn’t like. GET OVER IT! it’s not a big deal! Would you prefer It didn’t exist?
Oh and IE6, who cares!
“There’s an easy way to do it: do it” I TOTALLY agrre with this one!
@Dave Ward: I think you missed the point. Expando attributes aren’t really a problem that need fixing.
..But, while I’ll be the first in line to echo David’s get over it, a clean report from the validator is a quick way to rule out a whole class of problems when you are troubleshooting an issue. Ditto for validation-breaking css hacks.
Same goes for js syntax FWIW, another rich ground for get-over-its.
1 & 2 fail, markup shoud be valid. same goes with css.
people/company etc. should follow the STANDARS!
It’s hard to get over it, but you may be right!
I think a lot of commenters are missing the point of this post. The point isn’t “break the rules whenever possible”, it’s not to follow “the rules” to such an extent that they hamper your ability to get work done. Of course we should strive for valid HTML and such, but hey, if a client wants a link to open in a new window, I’m going to use target=”_blank”. It may break strict validation, but it works in every browser and gets the job done.
Like they say, you can break the rules if you know how to follow them. :)
So, uh, why isn’t there a “You don’t have to declare an HTML page with a STRICT doctype” get over it. =] Transitional is fine, and strict is just there for ego (and lots..and lots…of headaches and …well you get the picture.)
I admit it. There are items here that I need to get over.
Valid markup isn’t important? Really?
http://mayakovskij.posterous.com/what-the-fk-is-social-media-now-3
Look right below the slideshow box. That’s why valid markup is important.
David made an excellent point. Technology got that complex that it is almost inevitable to make mistakes so better embrace and use them instead of trying to be less than perfect.
However – since David is an expert coder – there is a difference between doing lame mistakes and conscious mistakes. For example, I dropped using /* */ for commenting out css elements/attributes during test driving my style sheets and simply use a / to make them invalid. The first way is the correct way in terms of css creating policy while the second is correct in terms of how browsers shall react to invalid code which simply means, that the second way is 100% valid in terms of css policy, too. Paradoxical, hu? ;)
Doing mistakes is the best thing you can do to learn and grow.
i totally agree with point #1 “Get Over It! Valid Mark Isn’t THAT Important!”, i had to create custom attributes for image tag just to get some effects work perfectly.
Wise words, David. The web would be a pretty dull looking place if it really were valid wouldn’t it? All you goody two shows with your little 100% badges at the bottom. Your pages are, invariably, a bit boring. I love the fact that it is a bit shabby, the seat covers are torn and a wing mirror sometimes falls off.
and IE… Well I coded my site right, so now it is your go.