On HTML and CSS best practices

Best practices are exactly that; best. Not ‘better’, not ‘good when…’ or ‘best if…’, just best. They’re always the best, no matter what.

This is something I learned whilst undertaking the single biggest project of my career so far; the complete (and not-yet-live) rebuild of one of BSkyB’s most trafficked websites. For years I’d been working on medium-sized projects where I strove to use as few classes as possible, my CSS was so elegant and hand-crafted and everything used the cascade. I thought it was beautiful.

I found my old approach isn’t best practice when working on a big site, therefore it’s not best practice at all… You can scale down the big site mentality to smaller builds, you can’t scale up small site mentality to bigger ones. With this in mind, how you’d build bigger sites is best practice, how you tend to build smaller sites is typically (though, as ever, not always) based on fallacy and myth.

I recently rebuilt my friend Sam’s design portfolio site. Typically I’d have used IDs everywhere, not used any OO and not really paid much attention to the length or efficiency of my CSS selectors. This would have worked but only because the site is small. Any attempts by Sam to scale the site up, add pages, move components or alter the layout would have been hampered by these methods. Instead I decided to apply big-site mentality and dropped any IDs, used an OO approach and made sure every component is reusable. The resulting code is incredibly flexible, very efficient and still looks nice.

It doesn’t matter if you’re building the next Facebook or if it’s just a site for the builder down the road; best practice is always best. You might not notice an inefficient selector on a small site, but it doesn’t mean that it’s not still inefficient. Just because you don’t notice something it doesn’t mean it’s not still happening.

Build every site like it’s a 1000 page behemoth because then it can scale; it may never need to, but it can. Building every site like it’s a piece of art, using convoluted selectors and rigid, ID ridden code, it can never scale, even if you want it to.

Your code might look like the Sistine Chapel, but if it’s a chore to maintain, or you find you can’t pick up a component and drop it anywhere with zero worry, then it’s not powerful. Code is about power before prettiness. You might feel dirty at first, but when you realise how nicely things fall into place using proper best practices you’ll see the benefits.

The only person who cares how pretty your code is is you. Your users want fast UIs, your clients want reliable builds and you and your team want code that is easy to maintain 6 months and a dozen client mind-changes down the line.

Best always means best, it has no caveats or conditions.

Further reading

By Harry Roberts on Sunday, December 11th, 2011 in Web Development. Tags: , | 14 Comments »

+

14 Responses to ‘On HTML and CSS best practices’


  1. Jack Simmonds said on 11 December, 2011 at 1:51 pm

    You are confirming something I had begun to suspect in the classes I have been through at Art Institute of Pittsburgh. Namely, the use of ID’s. My initial instinct, on first learning CSS basics, was to use classes where-ever possible. This is simply due to the restriction of one time use for an ID. ID’s tend to beget more ID’s where one class can be used for all those tags.

    As to the rest of the article-I need to go through the OOCSS site’s tutorial. They have a layout that I have been slowly working to perfect as I learn more about CSS, HTML, and PHP/JavaScript. The (OO site will save me a bunch of learning time by allowing me to jump straight to the goal. No sense in reinventing the wheel. I like that it appears flexible enough to avoid the “cookie cutter” look that I have come to loath on the web. That’s why I’m generally sceptical of all framework type applications. The OO method allows me to adjust the side columns, or leave one or both out altogether. It also allows for single or multicolumn, and multi-media, within the center column. I like it.

    I did notice that the center column isn’t quite flexible enough. However; once I get through the tutorial and understand the CSS sizing, that should be readily fixed. What I’m referring to in particular is that it doesn’t collapse far enough to be useful on a 300 pixel wide phone screen. Otherwise the page looks great and is plenty flexible to handle most site design needs.

    No, your article isn’t too preachy. It’s succinct and offers sage advice that anyone would do well to heed.

    jack


  2. Emile-Victor Portenart said on 11 December, 2011 at 2:19 pm

    I’m totally agree with you. You should juste related a good free book about oocss: “ scalable and modular architecture for css” here : http://smacss.com/book/

    And no, your article isn’t too preachy I think. ;)

    Have a good day,
    Emile


  3. Ivan Nikolić said on 11 December, 2011 at 3:50 pm

    This is something I’ve started to think about thoroughly by looking at my latest projects’ code. I’ve always strived to create beautiful and simple code, but when it comes to widening projects goal or working on big projects, that code in some cases becomes maintainability nightmare. Your article absolutely isn’t preachy and this is something our community should start accepting as normal. Thanks for sharing this with us, it really is good to see that there is also someone with these kind of little problems :)


  4. ginez said on 11 December, 2011 at 5:23 pm

    Hi Harry,

    Thanks for your article, food for thoughts as always.

    On this one, though, I feel like I have to ’softly’ disagree.
    Whilst I agree that best practices are always best practices, I believe something is missing: time.
    Flexibility gives you scalability, but in order to reach that flexibility you will have to spend more time on your CSS.
    There are projects that will not grow (eg. a website for a one off event that will go offline after few months).
    And if I have to spend (read waste) hours on a flebility that will never come handy, what’s the point?

    Also, depending on the result you want to get from your visitors, there will be sacrifices that you might have to take on (UI can be very different depending on your target audience).

    In conclusion, I feel like every project has its own priorities, those are the ones that will define what best practices to keep in mind and what we might, for once, slightly ‘ignore’.

    Rules are wondeful, but the can be (or need to be) broken in few occasions. (Still following the standards, I’m not saying going wild with coding would be good, quite the opposite!)

    g


  5. Michael Gunner said on 12 December, 2011 at 9:51 am

    I don’t think there is such a thing as “always best practise”. It’s reading too much into it.

    The “best practise” is whatever works “best” for a specific project. As Ginez mentions above, there are other factors such as time you need to take into account and these various factors may limit your approach. For example some times web designers are asked by clients to modify existing Wordpress themes, or create a website in a short time frame or to a smaller budget – in these scenarios you may be forced to compromise on your approach.

    And lets not forget, the absolute most important thing here is the end result. How you get to that end result doesn’t really matter – except to those of us who know enough about it to.

    I would agree though that developers need to think more about scalability when building. I’ve learned the hard way myself – all too often a clients demands will change half way through a project, or they approach you 6 months later asking you to add specific functionality. It’s important therefore that even with a basic site it is coded and structured in such a way this is not a problem to achieve.

    However, having said that, I don’t believe we should care too much to the point it’s costing the client too much more money and dragging the project out. I would love to hopefully one day drive a Ferrari, but I know to do that I will have to replace my Citroen – I can’t just paint it red and chuck in a V8 – and I think clients are usually aware of this with websites or you should make them aware.


  6. Andrew Heins said on 12 December, 2011 at 6:24 pm

    Front-end development is maturing into its own topic of software development.

    The tactics you’re describing aren’t new; in fact, they’re canon. As websites get more complex, front-end developers are running into the same walls that back-end devs (also known as programmers) solved ten, twenty… sometimes even forty years ago, and the solutions are the same.

    We even use the same terminology, “DRY”, “Object-Oriented”, etc.

    That we’re talking about this now, and being serious about it, means web development, as a field, has arrived, and it’s great news.


  7. Goran Daemon Peuc said on 13 December, 2011 at 1:24 pm

    Looking from the point of a professional, you will always want your work to be THE BEST to your abilities. You will push yourself to do it better and better with every new project. As ginez said in the comment before, there is the factor of time.

    Time is in constant collision with our pursuit of perfection. I would really love for my PSDs to be perfect. For each layer to be named correctly, and for each layer style to be in perfect sync with the rest of styles. But it is impossible if I want to get the project ever done.

    This is one of the posters hanging in the Facebook HQ:

    http://designforfun.com/images/portfolio/client/2010/quote_posters/arl_posters_6.jpg

    “Done is better than perfect.”

    Yes, stuff will break, yes, it might not be scalable and upgradeable. But it is done. And while it is done, the money flows in. We will fix it later.


  8. Craig S said on 14 December, 2011 at 12:22 am

    You discussed best practices for scalability. What if you don’t want scalability, and need best practices for quick development? Or best practices for some other goal?

    There can’t be one “best”. Developers can’t be inflexible


  9. rain said on 14 December, 2011 at 10:28 am

    how come are classes “left” or “grid” object oriented? am i missing something? no way they describe content or components. i think oocss movement needs to give better exaples how should i name my sidebars etc.


  10. Sumit Nagpal said on 14 December, 2011 at 2:47 pm

    Nice post for HTML and CSS beginner. Thanks


  11. Chris Garrett said on 17 December, 2011 at 10:36 am

    Good post Harry, highlights what we’ve found, the need for greater pragmatism and the ability to take a fresh approach to building websites.

    Frontend development has been held back for a long time by it being seen as a “designers” job, when serious developers apply their approaches to backend development, we end up with a much better engineered product.


  12. Matt said on 4 January, 2012 at 10:02 pm

    I agree with a less “quick and dirty” and more of a “what if this scales” approach, but what you seem to be advocating lacks pragmatism. Without considering the customers needs and budget, an OOCS approach is a solution looking for a problem.


  13. Kelly Johnosn said on 20 January, 2012 at 4:27 am

    I agree a little w/both sides. Having my pedigree in the advertising/design industry, the king is the idea/concept. Then the execution of that idea to best convey that idea to the audience. The right words/images/experience etc. The coding behind the scene needs to support all of that first. If it can be ‘pretty’ (what…indented? No comments? What really constitutes ‘pretty’ code?) then fantastic.

    Also, there is a strange trend with all this “What if?” Many times, it’s just as logical, valid and true to say “What if the website goes down and nobody sees it?” or even “What if you’re in a car wreck and lose your hands?”

    Follow the creative brief. Is it something that needs to be updated easily and/or soon? What’s the lifecycle of a site? Different depending on the person/product/service or company.

    I think one needs to think in the moment moreso than always in the future because the task at hand and communicating an idea via a website is what pays the bills first and foremost.

    But, by all means, if you can follow all the ‘practices’ and ‘guides’ forget figuring out something unique and go with the group. Sometimes, it can be good. Other times.. maybe not so much.


  14. Phil said on 29 January, 2012 at 5:25 pm

    Love OOCSS but don’t really agree with this post. Efficiency, maintainability, and flexibility often conflict with each other. The balance you need to strike between them varies by project.

    Overengineering is not a best practice. Knowing what you are trying to achieve is.


Leave a Reply

Respond to On HTML and CSS best practices

Hi there, I am Harry Roberts. I am a 21 year old web developer from the UK. I Tweet and write about web standards, typography, best practices and everything in between. You should browse and search my archives and follow me on Twitter, 7,791 people do.

via Ad Packs