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.
Putting Full CSS and Javascript in The Header
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.
A lot of beginners (and annoyingly enough, WordPress plugin developers) put their Javascript in their header. While this isn’t technically wrong code-wise, it can seriously slow down the loading of the page, especially if you have multiple scripts. Place your scripts in the footer of your site, so the rest of the site can load before your JS. While it might not make a noticeable difference on small sites, it can really speed a larger one up.
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.”
Your Thoughts
What are some of the coding mistakes you or other developers you’ve noticed make?
image by Foxtongue
About the author
Amber Weinberg specializes in clean and semantic XHTML, CSS and WordPress development. She has over 10 years of coding experience and is pretty cool to work with. Amber is available for freelance work, so why not hire her for your next project?
Amber, hopefully we can also start via comments, but how do you write your CSS? All in one line, one attribute per line, mixed, etc.?
Personally, I’ve switched to writing a mixed format CSS, with the majority of it being in one line, but I’ll occasionally put one per line if it is for styling of some special element.
Discuss.
I prefer one line CSS. It’s easier for me to read, quicker to find and cleaner IMO.
Definitely, one attribute per line for me. It’s so hard for me to decipher multiple attributes on a single line. To each his (or her) own though.
I concur. I used to use one attribute per line but now I prefer it all on one line. Also, if you run the google speedchecker thing it will suggest that you minify your css to one line if you are using one attribute per line.
Yes but a minified css does not necessarily mean you have to develop it minified.
Develop it to maintain readability, and then run minifying tools as part of your build process. You cant write truly minified code manually without losing your sanity, so why try
I recommend yuicompressor btw, which can minify both CSS and JS
http://developer.yahoo.com/yui/compressor/
Yeah I think it’s just easier to put it all on one line and then group attributes together (font styles, width and height, etc.).
I start off with putting css rules on one line. but if the line gets too long (around 100 characters wide), i’ll use one rule per line. horizontal scrolling is evil
I started with multi-line and went to single line. I’m now back to multi-line after learning about the “View > Toggle Foldings at Level” menu option in TextMate. This allows you to write in multi-line, flip to single line view for finding the next selector, then open that selector in multi-line view for easy editing. For production, I compress using http://www.cssdrive.com/index.php/main/csscompressor . This said, I like to have a bit of fun with ascii art and site Easter eggs so my files are not always 100% optimized. For example: http://trendmedia.com/wp-site/wp-content/themes/trendmedia-3.1/style.css Heh.
I use one attribute to one line except where there is only one attribute, in which case using multiple lines just wastes space and doesn’t help any in reading the CSS.
@Carpil – thanks for the link, hadn’t found the ‘real’ Yahoo one, have been using one found via Google for a few months.
First off…nice random foot in the bottom of the header pic
Great post though. While I try to hold myself to all of these rules, I honestly think that every rule can be bent every now and then. For example, I’ll confess that at times I’ll stick a style=”clear:both” inside of a div, rather than going to the CSS file, creating a class with just that style and then adding the class to the div. If I’m starting a project from scratch, I’ll typically do it the right way, but sometimes when I’m working with someone else’s code, I’ll put a *small* bit of inline CSS here or there…and I try to not feel bad for it.
I do that if the site I’m working on was coded horribly by someone else
i’ve recently tried the multiple line approach to css with the attributes in alphabetical order. i know it is kinda a pain – but i wanted to be consistent with all of my coding.
.mikeo
Interesting article, I agree with much but am confused by some.
What do you mean by “Using tags to space divs”? This seems pretty ambiguous and is not clearly explained. Did you mean tabs? Or if you mean tags, what tags are you talking about?
Regarding using a transitional doctype, there is absolutely nothing wrong with that. One should use the most appropriate doctype for the project in hand. If you’re developing HTML that will be used with a CMS that churns out unknown HTML that you can’t control, it makes very good sense to use a transitional doctype. It’s not simply a black-and-white case that Strict is right every time. One could still use the HTML 4 DTD if you really wanted, absolutely nothing wrong with that if the project warrants it.
It’s supposed to be using br/ tags but it executed the code lol, fixing it now.
If you’re coding for a CMS, you should know what kind of HTML it churns out, and most are validated in Strict, so I disagree. There’s no excuse for transitional doctypes.
Amber, you have a certain luxury in the kind of work you do that you know what CMS you’re using, but there are all sorts of other situations where the writer of HTML won’t know all the nuances of the system their HTML will be used in. I do a lot of this work for other very technically capable agencies, and they specify what DTD they need depending on the project. Indeed you can even write your own custom DTDs if you like.
It sounds like you might misunderstand what a DTD is for. A DTD is simply a document schema that outlines the elements and entities that can be used in your markup, their syntax and attributes. Once defined, a DTD can then also be used to give a validator something to validate against. If you want to validate your docs as XHTML Strict, great, use that DTD. If you don’t, no problem, use a different DTD.
A developer should choose the DTD appropriate for the job in hand. You state in your article that one should use Strict and everything else is void, but I’m afraid that you’re making a statement that is just flat out wrong.
I know what a DTD is for. I’ve done work in several different CMSes, including some in ASP which I had no experience with, and was still able to use the strict type. A person only uses a transitional doctype because they normally want to use inline CSS or obsolete tags. It’s like using an outdated version of a browser or OS.
I once had to work with a CMS that was full of errors. I still continued to use the Strict doctype, even though it ended up not validating, because it ensured that my own code was clean and correct.
Great post, agree with everything. I still haven’t been able to drop IE6 support. Sadly, my clients are still asking for it!
One thing I feel you did miss out there, in reference to another post, was “not commenting code”, but each to their own on that one
To the point of proper indentation/spacing, I’ve had another developer argue with me about this, especially when developing a mobile website. He was telling me that we should remove all whitespace between tags. I told him that I felt the file size savings was pretty negligible. But to him, a few kb in savings is better than nothing. Have you had anyone bring up that argument?
I don’t think there’s anything wrong with “compressing” your markup in this way, saving Kb can be very important on high-traffic sites. But don’t do actual production work with those files — always work from properly indented and readable files that you can easily understand and maintain.
I think you mean that you want to do production work with those files (the compressed ones), and do the staging work with the uncompressed files…
Yes, exactly, sorry if I was a bit unclear.
Yep I understand. He was trying to critique the code during the development phase, however, so it was one of those things where you could say, how about we wait until everything is completely done and then we can strip whitespaces. To be honest I don’t even think it would even save 1kb for the code I was working on at the time. Also you would have to save another copy of the file so that you can make changes in the future.
Nice article, especially the point about Validation.
You may wanna have a look at this though
http://validator.w3.org/check?uri=http://www.amberweinberg.com/common-mistakes-front-end-developers-make-when-coding/&charset=(detect+automatically)&doctype=Inline&group=0
I make that 13 errors, 21 warnings…!
Looks like most of the errors are the result of an unencoded ampersand in a link – I see this all the time with our posters. Should be an easy fix, just replace & with &
The errors are not from my coding but from the plugin Socialize This. Not something I can control.
Ah, I see – maybe you can fix it for them and submit it back (is socialize this an open source plugin?)?
I’m not sure. I know the plugin validated once before but after a string of updates, it doesn’t anymore. I fixed it once or twice, but it goes back every time you update as well.
Nice article. Nothing really new, but still nice read for all those “experts” who think HTML and CSS is easy
I am unfortunately the youngest designer in my area and I am forever hearing from clients that they were told by xxx designer down the road that I don’t know how to code properly because I don’t use php and css in the the html of my websites.
It’s fantastic to hear someone else saying these things out loud, its time to get real and start coding and designing properly.
Every customer I have who says “I was told I needed my website designed purely in php and for IE6″ I take them down the coffee shop with a laptop and spend an hour or two relaxing and helping them understand what it is they would be getting, how it should be done and what they need.
Too many people use old outdated methods, codes and jargon clients clearly don’t understand.
Nice article, i try and make all my websites confirm to strict DTD but sometimes not always possible some javascript elements throw it off. I have been attending a lot of seminers about web development and SEO lately and i think Ambers way of thinking as in the standards to follow is one of the two main view points of the industry. I found there were a lot of people that had the attitude of if something works and looks fine in all the browsers the way it is coded is not important.
In the end i think as too a point there is no law as such to the format and style of coding apart from what the browsers render it will always be a personal preference.
Personally i agree there should be set rules in place to make coding conform then maybe browsers would conform with the rendering. I think there should be standards set as in the end i know a lot of websites that can not even be accessed by disabled people as they do not render correct when all images and css is removed.
Each to there own is the phrase i end this comment on..
What do you mean too much javascript throwing it off? Your javascript should be in an external page and only referenced in the HTML, thus validating perfectly.
when you get javascript to add content to a page like for example the pre-made delicious Bookmark code to display lastest top bookmarks it throws off the validaction because it contain invalid characters whether it external or on the page when a page is validated live it is seen as code, as the javascript trys to produce html code but due to the linking to delicious it uses characters in the urls that are not validating. Yes it probally validates if it is validated by copying the code into the validator as the javascript is in a external file and not running, but to me that never gives the correct results must be live rather than direct input.
I believe Amber is having the same issues with the plugin Socialize as that throws up errors in validaction thats javascript. Its all the = and & in the URLS can be fixed but second there is an update reverts back.
You’re gonna hate me for this, so apologies in advance, but….
Run your very own blog page through w3c validator, and it gets
13 Errors and 21 warning(s)
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.amberweinberg.com%2Fcommon-mistakes-front-end-developers-make-when-coding%2F&charset=%28detect+automatically%29&doctype=Inline&group=0
Surely you should practice what you preach? ;D
I do practice what I preach thank you very much. Take a look at the errors and you’ll see they’re all from the plugin Socialize This. Not something I can control.
Also, that’s only on the single blog pages…
I agree with a lot of that yeah, but a few things I see people scared of now being tables and validation.
First I think that tables SHOULD be use, but only or tabular data. I mean, that is what they are for, and it is for more semantic to build a table around data, such as a pricing structure or something that to div the whole thing up. I think anyways.
Also with validation, I tend to not put as much weight on it as I once did, because frankly the web is advancing faster than the ‘validations’ can keep up. Meaning, that those of us that indulge in progressive enhancements like CSS3, will NEVER validate. That does not mean the code is crap, just that it is not part of the validation sequence…yet.
Any-whos-its, that my thoughts!
Great post Amber
LOL I actually don’t count CSS3 as “invalidation”. I actually never validate my CSS because of it. I was more speaking of HTML instead.
True true, I’m just saying
CSS3 and HTML 5 can be validated now using the W3C validator as normal as it intergrated the Henri Sivonen parser. Technology moves quick and opensource follows at a very close pace.
orly? Sweet I did not know that. While I was ignoring the validations because they did not do what I wanted they snuck up in there and did it!
Not sure how much you use HTML5 and CSS3, but a good read for HTML5 is HTML5 for Web Designers good useable techniques and back ups for none supporting browsers.
“And when we have tables,
we will need lines in them of various types,
and column headings and things.
And it will be good […]”
– Tim Berners-Lee
http://www.arminbwagner.com/text/the_tableless_table/
Agree with most of the points you’ve made, though I think some of them are a little idealistic. Conforming to a doctype doesn’t, in reality, actually help avoid cross-browser issues since browser support varies, browser defaults are different, etc. Also, be careful not to assume that just because something validates that it’s semantically valid. Let’s not forget that semantics are pretty subjective; is my menu an ordered list? unordered list? bunch of divs? All would be valid markup.
Look at the discussion/disagreement around new semantic tags in HTML5 like header/footer/section/aside (little of which is currently supported by IE, btw!)
An alternative I would have liked to have seen mentioned is the use of some sort of CSS reset (like YUIs) and/or CSS grid generation to help with more complex layout without resorting to abuse of floats or tables. CSS resets have saved me countless hours of cross-browser tweaking.
CSS inline I agree with, but tend to use it sometimes because I’m lazy/sinful. Doesn’t really slow crawlers down as they strip the majority of tags out anyways before parsing the content.
Indenting I agree with, too, though worth remembering that a lot of HTML is generated and that’s extremely difficult to keep clean. Better for the template to be clean than the resulting HTML since that’s what needs to be maintained
I don’t see anything wrong with a transitional doctype if it validates. Who’s to say that strict is any more valid? Horses for courses, I’d say.
Again HTML5 muddies the waters here somewhat, as it allows for both XHTML and HTML4 style markup, though I believe that technically you’re supposed to use one or the other.
You probably didn’t intend to come across as snippy in your reply to Carpii’s comment (the errors just look to be unencoded ampersands) but you’ve got to expect that if you’re writing about best practice that people will call you on it
Nice useful post all the same, nice to see someone who takes pride in their work.
- Paul
Overall, good post. I do still use BR tags here and there, though. *que tritone* They’re like the knife in Call of Duty. Using it can get you killed, but it’s so quick and effective in a spur-of-the-moment pinch. Yeah, it’s presentational. Yeah, it contains no info and says squat about the document. So many will cry to the sky that it’s anti-semantic. But is it really harmful unless used in excess? Not really. It’s still best to work them out for the sake of principle, but if that’s one of the only bad things you find in a site’s markup at all, here and there, anyone who calls the semantics police is just getting anal retentive at that point. There are more troublesome practices to worry about. In the end, treat them like one of those special grammar rules. When it doubt…leave it out. Just know how to use CSS to compensate (which is pretty darn easy).
Hi Amber, great article! To play off this a bit, I would love to see a section in your blog or maybe on codesnipp.it where devs can submit a site or page for peer review. The goal being similar to the open source movement in having others point out ways to improve your code.
Love this article, totally agree with everything you say. When it comes to modifying WordPress, I have seen a few occasions where changing the doctype to strict has caused some problems. Strict is great when you’re building a site from the ground-up, but other times, it can create conflicts with certain plugins and (crappily-coded) themes.
“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”
Seriously Amber??? Before you go off on rants about everyone else’s mistakes, learn to proofread your posts *which you never do*. I just couldn’t take it anymore. All your posts are LITTERED with these kinds of stupid typos. But since you’re on a holier-than-thou kick, I just had to call you out.
Hi Amber –
I just recently started reading your blog, and I dig it. I’m also relatively new to front end development. I’ve created about 5 sites in WordPress, and have been studying and playing around with XHTML and CSS for the past year. However, without formal training and not too much experience, I’m guessing that some of my code is messier than it should be.
Can you point me to any great books or resources that provide the nuts and bolts of clean front end coding?
Thanks!
I like the htmldog book and website – http://www.htmldog.com
I especially like the ‘bad tags’ section that explains what not to do and why.