Common Mistakes Front-End Developers Make When Coding
I’m by no means perfect when it comes to web development, however I always strive to improve my code with each new site I make.
I’ve noticed a lot of common mistakes made by both beginning and advanced developers (including myself). While some of these mistakes may seem trivial, they go a long way to making the difference between the average developers and the great ones.
Let’s take a look at these mistakes and discuss why they’re bad.
Using <br/> Tags To Space Divs
This practice was something I used to do often back in the table layout days, but sadly the practice hasn’t died out among the development community. When editing other developers’ code, it’s still fairly common to see developers using
<br/> tags instead of margins or padding.
While the document will still validate, this isn’t a good practice. Browsers render spacing inconsistently, so your layout will end up being off in each one. It also muddies up your HTML and crosses the line of separating structure from presentation.
Using Inline CSS
I was hoping that with the recent popularity in semantics and the separation of structure and design, that the practice of using inline CSS would disappear. It hasn’t
Not only does inline CSS complicated your HTML, but it also defeats the purpose of CSS itself, which is to have one place to keep your styles so the site remains easily updatable. It can also penalize you SEO-wise by making it take longer for spiders to download your website, since they have to navigate through CSS (which they can’t use). Inline CSS also won’t validate if you’re using XHTML 1.0 Strict, which brings me to…
Using A Transitional Doctype
Using a transitional doctype is akin to that annoying friend of yours who can never make up their mind between two choices. Basically, a transitional doctype is halfway between the last and the next doctypes.
If you’re going to be a developer, be a good developer. Transitional doctypes let you get away with rookie mistakes like inline CSS and other presentational markup that have no place residing in your HTML.
You should always try to avoid putting actual CSS in your HTML, even if it’s in the header where it validates. Remember, design should be separate from markup. The only CSS you should have in your header is the link to the external stylesheet itself.
Containers Within Containers Within Containers Within…
I think some developers are scared silly. Scared that if they don’t use six containers for that left content area, the whole site will blow up and the internet will point and laugh at said developer.
This can also be classified as a form of divitis, but it’s actually worse – it’s container divitis.
No, you do not need that many containers, when normally one or two should be the most you ever need.
Of course, there are always exceptions. I once had a client that had a ton of expanding rounded corner boxes within each other and they all had to work in IE6. I finally made the decision to drop support for IE6 after that one…
Tables, IE6 and Other Dead Things of The Night
People have always been fascinated with monster and the undead and developers are no exception. We love dead things like tables for layouts, making sites work in IE6 and other practices that should’ve been laid to rest long ago. Just stop already ok? There’s never a happy ending, you’ve seen the movies.
Who Needs Validation?
There are those out there who think validation is stupid and pointless. Well I think they’re stupid and pointless. Validation gives you a proper standard to hold your code to, helps prevent browser rendering issues and makes you responsible for that rat’s nest you call a website.
I don’t think I’ve ever seen any developer who doesn’t validate have good, clean, semantic good. They don’t exist.
Not Properly Indenting or Spacing Your Code
While the actual structure of your code is mostly up to you and what makes it easier for you to read and develop under, your coding structure should at least contain some sort of consistent indention and spacing.
I can’t tell you how many times I’ve viewed code with no indention, too many indentions (i.e. code goes off the screen with indents when it’s parent element is indented only once) and about 50 returns between one element and the next. This is not only very, very ugly, it increases file size and makes it near impossible for the next developer to figure out what’s going on.
Thinking HTML and CSS Are “Easy”
I’ve heard some developer “experts” claim that HTML and CSS are easy and everyone should know how to do them. This is not only a HUGE annoyance to front-end developers like myself, it’s also untrue.
Yes, learning the basics of CSS and HTML are pretty easy compared to backend languages. However, becoming an expert in HTML and CSS is NOT. I know plenty of backend programmers who know several languages, but still can’t write clean, semantic HTML. Nor can they figure out the basics of validation (or write a simple paragraph without 100 errors).
Anyone can change font colors. But it takes a real expert in front-end development to code a complicated site from scratch that’s validated, clean, semantic and cross-browser friendly in under a few hours without looking. So no, real HTML and CSS isn’t easy.
Picky Picky Picky!
I’m very, very picky about the way HTML and CSS is written, because this is what I’ve spent most of my like trying to perfect. I think it’s important to hold yourself to the highest standard no matter what you do. As mom always said, :if you’re going to do it, do it right the first time.”
What are some of the coding mistakes you or other developers you’ve noticed make?
image by Foxtongue