CSS Pitfalls for Web Designers to Avoid

The stylistic language of CSS has been among us for many years, yet while it possesses the ability to engage and entrance our visitors with increasingly complex feats of layout and design engineering, poor decision making can affect the final outcome. While often due to a lack of awareness of the implications or from personal choice, a number of potentially problematic issues exist that can result from innocent decisions. This article aims to correct these common practices.

Proprietary Code Isn’t Demonic

The first pitfall that needs to be addressed is the common misconception regarding proprietary code such as webkit transitions and animations. One of the major reasons why vendor prefixed code is frowned upon by many in the industry is simply because it doesn’t validate. Because the code was not set or sanctioned by the W3C, those who rely on the validators see it as a mistake rather than a helpful feature which can boost a site’s beauty which is rather a shame when you think about it.
As designers, we regularly find ourselves trapped within code. With CSS having a specified limit on what properties are valid, custom properties are given an opportunity to push the boundaries, test new features like CSS3 before it goes final and not intrude on the general layout. Yes of course, if you make your code depend on them, it’s likely to break, but surely you make your CSS progressively enhance to such code and update your site anyway, so there’s not really anything to worry about! Using proprietary CSS isn’t a bad thing – it just requires an extra bit of attention and maintenance.

Ignoring Browsers or Mobile Devices

The next pitfall we can address is one which seems to be trickling into the mainstream, but not at a proportionate pace in relation to its visible growth. Like them or not, many cellphones and handheld devices now have Internet access, and not just that clunky WAP system which existed in the 90’s. Many smartphones and featurephones actually have a fully fledged browser within them. With this in mind, why do so many people still remain loyal to testing in desktop rendering engines?
People are using the web in all sorts of ways they didn’t in the past. Televisions are being enabled, phones are already enabled and there have even been refrigerators with Internet access in the past though it’s fair to say that it didn’t take off. Some people don’t test outside of the desktop because of perceived costs this is less of an issue with the range of good emulators. It’s also not fair to say that the usage numbers don’t justify the testing after all, usability should be paramount. If your site doesn’t already work on handheld devices, it’s now time to consider making the experience better.

Inline Style When External Will Do

Many standards advocates have been promoting the importance of separating structure, behaviour and style for the reasons of ease of maintainability and the advantages of caching, yet still to this day there are many individuals who make use of either the style attribute, style tags within the header or even resort to using deprecated stylistic elements within their code. While the more perceptive and up-to-date amongst you will already avoid this at all costs, the bad trend just seems to continue!
In this case the resolution of such problematic coding is education and while we all know that taking that CSS, stripping it from the page and breaking it into a separate file will give you the amazing and cool bandwidth savings that browser caching provides possibly more if you have GZIP enabled on the server, the necessity of many CMS products, prebuilt apps and WYSIWYG editors to continue applying style in such a manner requires immediate attention. There is rarely a case where internal style is of more use than external, and as such, learning to avoid repetitive coding is worth the effort.

Keep it Together (Less Files are Good)

Following on from the previous pitfall, something which plenty of active designers who code beyond the novice level will encounter is the separation of stylesheets into smaller files. While the breaking down of style into separate files may serve a purpose if you update your CSS files regularly and wish to maximize caching, the argument that separate files are easier to navigate seems to showcase the IDE or editor’s lack of code tracking methods than a real need to invoke added HTTP requests.

Putting it simply, editors like Notepad++ have the ability to cleverly collapse code, which removes any potential issue which may result from lengthy CSS files. If your current editor doesn’t have such a function, it may be worth changing to a tool that does as unless you update your CSS regularly, the extra HTTP requests to the server are waste produce. While this may seem rather picky, it’s easier from the browser to navigate “view source” in a single file, and as media selectors can target specific conditions like print styles or certain widths, you can still have the separation within a single file.

Typeface Dependence and Unit Values

Finally it’s worth mentioning the pitfalls of typeface and unit value dependence. Back when the web was young, the need for selecting relatively Websafe typefaces was critical, yet while the lures of @font-face may give another impression, this still hasn’t changed. So many sites assume that a font has been installed or font-face will be available that many simply ignore the traces of usable fallback mechanisms. In addition, tonnes of sites still use PX units on text which is crazy for IE users.

With Websafe fonts, it’s easy to say that there’s no such thing as most typefaces can be uninstalled along with font-face downloads disabled, and with CSS3 not being available everywhere, it’s still very important that we acknowledge those devices. When you make use of the font-family property in CSS, always ensure that you have a proper stack formed with fallback options, it’s that simple. As for measuring text unit’s in PX, while the Zoom function in every browser will handle the task of resizing it with ease, IE’s Text Size accessibility option (even in IE9) can’t resize PX measured text!

Think Before You Style

There are plenty of mistakes we can end up with while coding, from forgetting the hash character in color hex values to spelling the properties incorrectly or even forgetting about case sensitivity in CSS selector names. While the journey of getting to grips with CSS may be long and slightly daunting for the less experienced coder, the need to think about what you’re doing, exploring the risks of using both standardised and proprietary code in browsers and staying in control of your site is critical.
For the more advanced CSS developers out there, the terrors of hasLayout and the new frontiers of mobile design will remain heavily in our focus as will browser compatibility. For beginners, the way in which you build, structure, organise and maintain your code (and getting past those simple yet somewhat annoying validation issues) will be paramount. In either case, it’s acceptable that we will all suffer at the hands of our own mistakes (or those of browsers) in the future, so the best thing any of us can do is stay vigilant, read the specifications, keep learning and stay on top of what’s new!
Questions
Do you agree with my observations that vendor prefixed codes can be helpful? Are you a fan of font-face and non-Websafe typography? Do you test or build for mobile devices? Or are you the person who still uses inline styles or tonnes of separate CSS files? Let us know in the comments!