By Craig Buckler

Do You Adhere to Strict BBC-Style CSS Coding Standards?

By Craig Buckler

The BBC website is one of the most popular destinations on the Web. It has a page rank of 9 and a reputation for quality reporting and resources.

Internally, the BBC also has some of the strictest guidelines known to web developers. It’s not just browser issues either — every aspect of technical development has a set of published rules.

I’ve been studying the recently-updated CSS Standards. They’re all best-practice techniques but they go further than many company policies!

General CSS Principles

The BBC uses XHTML 1.0 strict for content and the guidelines state it must be readable without CSS or JavaScript enabled. This is important but it’s often overlooked by many developers as they rush to add the latest jQuery widget.

Most browsers (or extensions such as the Web Developer Toolbar) allow you to disable CSS and scripting. If the content isn’t readable, you can guarantee that Google and screen readers can’t see it either.

According to the guidelines, all CSS must be valid according to a published W3C recommendation. I suspect that causes a few headaches as it appears to rule-out vendor-prefixed properties such as -moz-border-radius and -webkit-box-shadow. However, the BBC site does use them sparingly.

!important is banned because it overrides user styles. That’s a little harsh since it can be useful for IE6 fixes. That said, I’ve been guilty of abusing it for quick and dirty hacks when I should have addressed the root of the cascading problem.

Finally, if you’ve abandoned IE6, spare a thought for the BBC coders still testing in IE5.5! CSS is particularly nasty in that browser: it tries to parse the properties but fails dismally.

Implementing CSS

All CSS is implemented in compressed external stylesheet, although CSS in the HTML head is permitted when a rule is required for a specific page.

Inline styles are banned. That’s good. Any coder found using them should have their web development license revoked!

Interestingly, external CSS files must not be loaded using @import because it impairs browser caching. Does it? I doubt that’s still the case in modern browsers.

Typography and Color

A single generic font name of serif, sans-serif, cursive, or monospace must be added to the end of all font-family properties. Again, this is something developers often forget: not everyone has Arial or Helvetica on their PC.

I loved the double-negative rule:

Typographic sizes MUST NOT be specified in units that are not resizable in all browsers such as px and pt, except for in print stylesheets.

The BBC recommends either em, % or keyword values and text must remain readable when the size in increased by two steps in any level 1 browser. I bet that’s a testing nightmare!

Finally, developers must define a page background color. I’ve had that rule tattooed to my forehead after viewing one of my sites on a PC where the default had been set to a sickly green.

Developer Heaven or Hell?

If you’ve been working in the industry for a while, you have probably absorbed many of the guidelines laid down by the BBC. But how do newer developers cope? On the positive side, the expectations are well documented and it helps coders avoid basic usability mistakes. However, development is tough enough — most people would struggle to contend with multiple rules and regulations defined for 24 inter-related technologies.

Does your company enforce strict coding guidelines? Are they set in stone or reasonably flexible? Are they sensible or ridiculous? Are they updated regularly or are you still coding for Netscape 3.0? Do guidelines help or hinder your day-to-day development tasks?

I’d also be interested to hear from any developers at the BBC … do you follow the rules to the letter or have you sneaked in the odd !important when your manager’s not looking?

  • devolved

    I’ve always coded to those standards … except ie5.5, I’m conscientious not stupid :p

    • Julius

      Yeah you are right! No need to actually test it in IE5.5. IE is buried! Nailed it!

  • JR

    I stick to the general best practices, but I certainly don’t ascribe to that sort of asceticism. If the BBC finds it important enough to pay for, then bully for them. (Of course, the BBC is funded by the government-mandated TV license fee, so they don’t have to worry about pesky things like ROI or whether they’ll be in business next year.)

    If I quoted my clients the kind of price that would accompany that, I’d never get a job. Small businesses just aren’t going to pay for hundreds of hours of testing for obsolete browsers and optimizations that shave a hundredth of a millisecond off the load times for 0.01% of their visitors. What the client is willing to pay for is what gets done – I’m not running a charity or a tax writeoff.

    • Peter Pan

      The question is, will you ever get to work for a big client if you don’t have the correct code examples to prove your worth?

  • I consider such coding practices to be just part of what separates professionals from people who just call themselves professionals.

    I disagree with some of it like the sending CSS through the YUI compressor before serving to the user, since it violates their own rule about making it legible for maintainability — besides CSS compressors basically just strip whitespace, if that 1k of savings you should have after yanking whitespace adds up to enough to matter after it’s compressed by gzip then you’ve probably got something wrong with your formatting or are using more CSS than should be neccessary. (they do enable gzip, right? … and if the server is configured right the compressed copy should be cached server side… )

    You know, too much CSS like using fat bloated PRESENTATIONAL class-name train wreck ‘frameworks’ like YUI, Grid, Blueprint, etc…

    That said they don’t go anywhere near far enough IMHO on the markup rules… and disagree with some of them (see h1 which they are using in a manner that wouldn’t work or even make sense with most pages I write)… See their heading structures which make no sense whatsoever; the headings for the navigations and toolbars as subsections of the local content and not the site? some of the tags on the ‘presentational tags’ that ‘must not’ be used — like B and I still have a proper place in modern markup — since STRONG and EM do not mean the same thing as I wouldn’t be adding emphasis to a book title. (though I agree on every other tag listed…)

    But rules are good for maintainability — even if you disagree with the ones in use at an employer you should at least have them and follow them so everyone is working off the same page, instead of ending up with the jumbled hodge-podge disasters many companies sleaze out any old way.

    I have some of my own rules that I follow:

    IE conditional comments should never be used for CSS, as there’s no excuse for bloating out the markup with 256+ bytes of code for something that in most cases can be handled by a couple 20 byte haslayout triggers or the occasional display:inline; This is particularly true if you are sending different heights/widths/paddings/margins to specific browsers as it likely means you just wrote your CSS wrong in the first place. (there is NO REASON to EVER have to do that apart from garbage markup and worse CSS!)

    Pages should not be allowed to have more than 40k of Javascript UNCOMPRESSED unless it’s a full blown web application like google maps. Of course that rule right there means you could never use the convoluted cryptic nonsensical ‘frameworks’ like jQuery, Mootools or YUI that just makes javascript harder to code with more code in the name of making it easier and less code. Let me just say that again, makes it harder to code and makes you use more code in the name of making it easier and less code… Whiskey Tango Foxtrot?!? I can’t believe anyone is DUMB ENOUGH to use those in the first place!

    “Not every ejaculation deserves a name” — which is to say do NOT just start slapping div’s around every single element and slapping classes and ID’s on everything. A DIV to group a bunch of semantic tags into a wrapper you can inherit off of? Fine. A empty DIV sandbag as a hook for your presentation? FINE. Wrapping a DIV#header around your site logo and menu for no good reason? GARBAGE CODING.

    Code to content ratio of 3:1 should not be exceeded. That means if you copy just the text off your page as CDATA, and compare it to the total HTML source code, if there is more than a 3:1 ratio you’ve probably screwed up somewhere or have bad coding practices… like tables for layout, slapping div’s around everything and classes around everything for stuff you could be applying to your semantic tags instead, static scripting inlined in the markup, static CSS inlined in the markup, etc, etc…

    I do NOT advocate CSS inline in the markup, even using the STYLE attribute — and the reasoning behind this is twofold. First, I don’t allow the total CSS for a website to exceed 48k per media type. If you have more than 48k of CSS your layout is likely inconsistent across pages and you aren’t leveraging condensed attributes or inheritance properly. Second, Putting the extra 4-8k of unique page CSS in the primary stylesheet can be considered pre-caching; You are sending the information before they load a sub-page, making the subpage appear to load faster. Mind you, I work on things like forum skins a lot where sending the unique info in the markup for something like say… a topic list, would actually chew MORE bandwidth.

    See why I cringe when I see people asking for help on a template they just built that so far only has a single page of the site coded, and they already have 50K+ of CSS and 50k of markup for half a K of content.

    Bottom line — at least they’re trying; that’s more than I can say for the majority of people working on large projects like say… WordPress, Magento, Joomla… You stick your head into the code on those and it’s apparent that consistency or even things like the WCAG are outright foreign concepts to them. (Much less secure coding practices)

    • Thanks deathshadow — some good points there.

      It’s a controversial issue, but I agree with your stance against conditional style sheets. For me, it’s too much like browser sniffing and they’re simply not necessary. IE bugs can normally be fixed with a property or two which have no detrimental effect other browsers.

      The main argument for using conditional CSS appears to be that you can easily remove the browser-specific styles at some point in the future. But:

      1. You’re making it more difficult to add styles in the first place. Rather than having all properties under one selector, you’re splitting them into 2 or more files.

      2. Why would you ever remove IE6 fixes? The browser will be around far longer than your current site!

      While I won’t say they’re never necessary, it’s too easy to rely on conditional CSS to work around problems rather than fix them.

      • Vin

        If you haven’t found a need for conditional stylesheets then you must fall into one of these camps:

        1) You maintain a simple, low tech site.
        2) You cater to a narrow selection of browsers
        3) You take drastic steps like degrading the experience in older browsers significantly in order to avoid extra markup
        4) You don’t cater to corporate america where browser choice is diverse or schools where technology is usually quite old except for administration.

        I’m the head front end developer for two massive web apps used in corporate and education markets. It would be IMPOSSIBLE to deliver either of them with any sort of modern approach without conditionals. Keep in mind that we MUST support ie6 through 8 as we have clients using all versions in large quantities at whim of their IT directors, who usually prefer a specific version or just dont’ want to update 100s of computers.

        IE conditionals are one of the best ideas to come out of MS, AND if used correctly… you’re not delivering a completely new style sheet, just a small select amount of “fixes” for specific versions.

      • I said it was controversial, but it’s “no” to all 4 I’m afraid, Vin (well, OK, I haven’t done much corporate US work, but UK public authorities are probably worse).

        You may need to be a little careful with mark-up but you won’t always need additional HTML. And I’m yet to code a design that required conditional CSS. That’s not to say I won’t need additional properties or (rarely) a selector that fails in IE6, but it’ll all validate without errors (no nasty hacks).

        The reason it’s possible simply comes down to many years of experience with IE6 bugs. I know what’s likely to cause problems and how to fix them. Early testing is essential too.

        Part of the trouble with CCSS is not always used “correctly”. It’s too easy to apply a quick fix. Then another. And so on…

      • noonnope

        The main argument for using conditional CSS should be performance.

        If you look at what Google has to say about optimization:, it appears that:

        “Descendant selectors are inefficient[…]”.

        That means you are stuck with only descendant selectors if you don’t catter for IE separately.

        The benefit of being able to use efficient selectors seems a good enough reason for me to use conditional CSS. The style for IE as opposed to the style for the other UAs can and it should be radically different. The difference should not only consist from hacking IE bugs. Otherwise, updating to new UAs version just for having the latest but not to benefit from the technological CSS advance they may provide, and being stuck with selectors from 1999, that would never mean progress.

      • Thanks noonnope, although I doubt even the most cumbersome selector would be slower than parsing a conditional code tag, checking the browser/version and loading another file!

        I’m not saying you can’t use modern selectors, either. For example, table row zebra-striping is easy with modern CSS but IE6 can’t handle it. That’s unlikely to be a major issue — IE6 users can still see the data. If your boss doesn’t like it, it can be fixed with a smidgen of JavaScript or server-side code.

        You’ll certainly have IE issues if you’re using advanced selectors for major layout blocks. However, if you create a site that works in the lowest common denominator, you can use progressive enhancement to improve it for modern browsers.

      • noonnope

        Conditional CSS probably means slower IE experience. But faster for about 60% of the rest of the users.

        You talk about zebra tables not working in IE6. That’s about graceful degradation, rather than about progressive enhancement. Which disqualifies the concept of not using the newest CSS available. And questions the need for CSS3 for at least another 10 years?

        Always creating for the lowest common denominator. Until CSS. Progressive enhancement is about CSS. You can however, make a progressive enhancement using CSS and JS, and provide a graceful degradation for UAs needing it. The lowest common denominator for CSS says that: a graceful degradation of a progressive enhancement.

      • Mmm. I doubt it’ll be significantly faster for non-IE users: we’re not talking about masses of CSS here, just a few fixes.

        As for progressive enhancement vs graceful degradation, you’re right, but it really depends which way you approach it. This is a simple example and you can label it whichever way you wrote it.

        Finally, remember we’re talking about building a site that has IE6 as a level 1 browser. That doesn’t affect the future of CSS3: it just means we’re making it work in IE6 early on and without conditional CSS.

        In my experience, CCSS is only used when IE6 is tested at the end of the project and all hell breaks loose!

      • noonnope

        It’s funny. I thought we did talk about using the CSS technology that’s faster for the other browsers: faster CSS selectors, UAs that don’t have the stalling updating problem IE has.

        It’s also funny that CSS3 implementation hype is about rounded corners and text shadow and @font and not about the real deal: faster, custom selectors.

        My plan is this: use the current standard CSS, that IE doesn’t support, for my lowest common denominator markup. Together with JS, I will have a progressive enhancement of the user experience. This allows me to throw at my page all current web technologies, not restrict my self to those from 1999. And this way I can even test new technologies: HTML5 and CSS3.

        For IE, I will provide a massive graceful degradation, through conditional CSS. This way, I will provide a faster and richer experience for 60% of my visitors. As opposed to providing them a most likely incomplete “progressive enhancement”, due to the restriction I impose my self following the lowest common denominator.

    • Andy M

      Im not sure ive understood your argument about compression.

      For almost every site on the net yui compression on a css is probably not important, which is the point you were making i think. however in the case of a site like the BBC with its volume of traffic, saving 1k of whitespace could easily build up to saving 0.5gb per day due to the number of users.

      If you have 10 page hits per hour its not worth it, if you have 100,000 page hits per second its a totally different story

      doesnt google ommit the closing body and html tags to save of traffic?

  • Roger Spencelayh

    Really interesting article, thanks. To put it another way ‘Well I never knew that!’ It does though explain the site’s consistency and how professional it looks.
    The problem with so many sites these days is that there is so much software out there for building sites, that anyone can build one – and it shows. And Microsoft didn’t help by encouraging people to build sites using Publisher or Word – not a good idea.
    Going back to the BBC rules, I love the CSS rule External Style Sheets only and no inline styles. And as for the Font rules, it’s just common sense really. I’ve just recently had a moan at someone who was looking for people to test the mobile version of their site. First thing I found was you couldn’t re-size the font as it had all been set in Point or Pixel sizes. Total waste of my multi-touch HTC screen.
    Keep up these good posts guys.

  • Great post Craig. It would be interesting to know whether they have automated testing that flags stuff like !important or missing backgrounds. A lot of it seems perfectly automatable.

    • frazor

      Yes, we do have a team of webmasters who run a series of automated and manual checks across the site, both on request, and in a random spot check kind of way.

  • Darren884

    The BBC has a great team. I am pretty strict but I will admit I use !important.

  • Great idea this set of rules. I worked for some time for FranceTelevisions (which is the french equivalent to the BBC), and there was not such rules. I’d love there had been !.
    When you maintain a lot of web sites that interacts with eacgh other, you need coding rules (as structuring, designing… rules).
    Like every set of rules, I think some are a bit strange, inadequat or so but when you look at the code of their pages, even on the homepage, you see that they don’t respect it… : parameters on the calls to stylesheets, inline styles, script calls everywhere in the page and so on.

    I have my own rules that looks like those, but less strict.
    For example, inline styles : yes, that’s bad. But when you just need to apply a simple style on an element, that this element is unique but drowned into the code, why applying an Id to style that ID in the head ? Inline styles exists, never use them would be just stupid IMHO.

    • Nooooo! Never use inline styles! A 5-minute quick fix today will turn into a 3-day nightmare tomorrow. If you can add a style attribute, you can add an ID or class (and that’s not always necessary).

  • kevinvs

    Glad to see Sitepoint covering the topic, also. Kudos to BBC opening up their standards for public display.

    Level 1 styling should not be used because it ruins the presentation and content separation. Throwing in another template or css will cause issues in the long run. As Craig pointed out, why not use Level 2-3 style instead since it takes up less real estate and hassle? Make it page specific if you’re afraid that it will get lost in the shuffle.

  • @JS – actually public money is only a small part of the BBC’s income; they do have to think like a private competitive business, just like any business.

    Doesn’t stop them acting like a good-old-fashioned British public monopoly .. but still :D

    • frazor

      Its not just about the money though, we also have a charter we have to abide by.

  • fn64

    it’s good to hear that at least one big company pays attention to the quality of code on their sites.

    thumbs up for bbc.

    i want to ask all so-called ‘webmasters’, hey, what a bloated piece of crap your markup should be if you can’t even test it otherwise than using !important ? and you call yourself developer? wtf?

  • USPatriot

    Why would the yanks (me) care about British Standards? No offence, but it is a little pretentious for you to even make this topic. It’s like me telling the Brits they should follow CNN standards in the U.S. Make any sense? Thought so.

    • You seem to be under the impression that Sitepoint is an American site with an wholly American readership. In fact, it’s an Australian site, with writers and readers from around the world. Seeing what people do in other countries is actually interesting.

      Although I suspect you’re just trolling.

    • @USPatriot
      Why do you assume these are “British standards”? The BBC guides are best-practice techniques for one of the most popular sites on the web.

      Has CNN or any other major website published their internal development guidelines? If so, then yes — I’d love to write about them.

      But Patrick is right … you’re just trolling again. I’m sure you can find other sites more willing to indulge in a little casual racism!

      • USPatriot

        Soooooo, let me get this straight. I am a racist because I stated an argument against companies’s dictating the future of the web, which entails, what we should and shouldn’t due. That is racist? You are reaching an delusional. Why does SP employ this hack? Calling people racist because I respectfully disagreed with you (by using, “no offence”) did see that part did ya? I’m not even going to attempt to read another article as you have no relevance to the industry.

  • benfrain

    This is not meant to be inflammatory; merely an observation. Like most web designers/developers, I’m always trying to improve and have learnt some good nuggets just through this post & replies. However, I find it quite interesting that many of the people who seem so aggressive (to the point of rubbishing any developer that doesn’t follow there coding conventions) about coding best practices, seem to be completely lacking in following design ‘best practices’. Like colour technique, layout, UI design etc. In summary, the code may be great but the visuals are not. Perhaps this is merely the divide between a designer and a coder?

    Regarding the original post: the BBC has a remit (which we all in the UK pay dearly for, whether we want to or not) to cater to everyone in the UK. And their dog. And the gnat that sits on the dogs back. Basically, if a device can load web pages, the BBC probably has to support it. That’s the rub of being a public service. But don’t feel sorry for them, they have everyone’s cash to achieve that dubious goal!

    Regarding code, ultimately, the only internationally recognised standards I’m aware of are the W3C. They may be only a starting point for good ‘best practices’ but the standards they have produced are the only ones I consider ‘valid’ (pun intended).

  • … because I stated an argument against companies’s dictating the future of the web

    It would seem to me, to be a dictator of anything — an empire, a country, even a letter — you have to, by definition, be in control of that thing. So, it’s hard to imagine how the BBC could be dictating the future of anything but the BBC.

    After all, the W3C is the agreed worldwide authority on how the web should be built, and ultimately not even they can dictate how you construct your pages — it’s just a recommendation.

    This is just a peek into the working processes of a large global web entity. It’s no more or less relevant than publishing a style guide from Yahoo or Amazon or WordPress. I wish they all published their style guides.

  • subwayslim

    this page doesn’t use either validated HTML or CSS……….

  • cahura

    The BBC sounds like a Developer Boot Training Ground! I like the strict coding discipline, but to still test in IE5.5… !!!

    I would like to hear how the BBC coders get on too – so help them God.

  • Webnet

    In my opinion standards only mean so much. Browers and major search engines are supported to read non-standardized code (assuming it’s at least somewhat standard and you’re code isn’t all jacked up) anyways, so why go through a lot of effort to make sure it’s standard?

  • reluctantly_optimistic

    @uspatriot: Aw, come on, you know this web thing’s a passing fad anyway. Excuse me, the phone’s ringing and I have to climb the pole to answer it.

  • Howdy_McGee

    I’ll stick to certain guidelines but if I can code “javascript” functionality using css (I.E. Drop Down Menus) that don’t adhere to those guidelines then i will. My company follows pretty strict guidelines of IE7+ which is pretty awesome so I can do anything!

  • Simon

    The rules you refer to about browser support and such are only applied to the public service (license fee funded) side of the BBC. Fortunately I work in BBC Worldwide and we can afford to choose what we support (Last main thing we delivered was the homepage).

    Working on a large project at the moment that will use many elements of HTML5 and CSS3. Pretty glad I don’t have to support IE 5.5 :)

  • Kevin Rapley

    This is nothing, not only do we abide by many of the rules specified by the BBC (we don’t cater for IE 5.5 any longer), but we also define exactly how opening and closing braces should be formatted, the order that properties should appear in, where line returns and spaces should occur, how floats should be cleared, favour shorthand properties, and lastly how the CSS document should be structured: Global Styles, Clearfixes, Typography, General Styles and Page Structure etc.

    It makes a lot of sense to have a house style which each member of the team abides by. When you come to work on someone else’s project, you will feel right at home and be able to make amendments quickly and safely.

  • Richard

    This clearly shows why the BBC website is so well used and respected. What impresses me most about the guidelines is how readable and easily understandable they are (the odd double negative aside).
    Of course there is a debate over whether this is good use of UK taxpayers money and that also extends to whether the BBC should be providing most or all of this content free to the rest of the non-licence-paying World.
    It shows just what can be achieved by high levels of professionalism and whilst I wouldn’t agree with everything in the guidelines (for example I no longer think that coding font-sizes in % or ems is an absolute necessity) it clearly works for the BBC and there needs to be this level of control over such a large site.

  • frazor

    Thank you all for you constructive discussion of the CSS Standard.

    We are a W3C member organisation and of course, like most developers worth their salt, take W3C standards compliance seriously. Our own internal standards are a mixture of best-practice, rules to avoid common pitfalls, peculiarities relating to how we host and scale our content, and a light enforcement of house style.

    The current version of the document was a fairly ruthless rewrite to make it shorter, more succinct, and removal of some legacy rules that are essentially obsolete – but of course there’s still a few contentious issues in here. The development community at the BBC (the public service that is) takes the quality of its code, and its technical solutions, seriously. However not all of it is built in-house and a lot of it is essentially legacy content, so sometimes things fall through the cracks. But please remember we have millions of pages so its not easy to track.

Get the latest in Front-end, once a week, for free.