Oct
21st
08
Tue
21st
08
12 Tests for Evaluating a CSS Implementation
Recently, I was asked what 3 to 5 things I would look at to determine whether a website was well implemented from a styling perspective. How do you evaluate whether the markup and CSS is coded well?
Well, I couldn’t keep it to under 5 things, but instead came up with 12 tests for evaluating a CSS implementation. It isn’t an exhaustive list, nor does it constitute a complete and thorough code review of a project, but it will help you quickly evaluate a site or a developer for hire.
- Cross-browser support. I would generally do a series of quick tests using the desired browsers for the project. For sure, I would want to see how it renders in IE7, FF2+, Safari and go from there. If IE6 is a requirement (don’t scream, it actually may not be), this would be the next thing to evaluate. IE6 support can be a key threshold to overcome and can make or break a styling implementation.
- How does it scale? I would try increasing the font size (using ctrl + in Firefox) to see how the website structure holds up at increased (and decreased) font-sizes. Not only is this important for evaluating accessibility, but it can bring to light poor coding practices that aren’t apparent at the optimal browser configuration.
- No tables used for layout. In modern CSS implementations, tables should not be used for layout (there are only some exceptions). If the page layout is achieved as a series of nested tables and spacer gifs, it is a sign of poor implementation (or a very old one at the very least). Simply put, table-based layouts won’t allow you the flexibility to move things around in the UI without a series of headaches.
- No inline styling. Pretty much all styling should be in the CSS style sheets – not inline on elements or embedded in the <head> tag at the top of the page. Separation of the templates (html) and styling is crucial for maintainability. This rule holds true for JavaScript also. Setting styling properties within script is (most often) a no-no.
- Semantic mark-up. Ideally, semantic markup should be used when laying out elements. Wikipedia defines semantic HTML as the “objective and practice of creating documents with HTML that contain only the author’s intended meaning, without any reference to how this meaning is presented or conveyed.” Doing so provides greater accessibility (and in turn, better SEO), and consistency in styling.
- Reduced browser hacks or well thought out hack management. Simply put, support for IE6 and a myriad of other browsers is difficult. Understanding how a site overcomes this obstacle is an important step in understanding the quality of the implementation. Hack management most often refers to conditional commenting of IE only style sheets, but it can comprise other techniques for targeting IE.
- Performance. What is the site’s YSlow score? Although an A is probably unlikely for most sites, understanding how it fairs with performance metrics like http requests (due to style sheets, script tags and images) is a fair acid test for performance.
- Classitis. I think we all use a few more classes than we hope by the end of a project, but overuse of IDs or classes in the effort of styling a page is a sure sign of a poorly developed site. It can make debugging and future maintenance a nightmare, and hint at the lack of planning during implementation.
- Turn off CSS support. Turn off styling to see the DOM flow and the overall page structure. Seeing the DOM from top to bottom will give you a quick understanding of how it is structured and how other devices (such as screen readers and mobile phones) might interact with the site.
- Turn off images. Much like turning off CSS, removing images will help you see the developer’s coding practices in action. Are images used to display text - particularly key items like navigation? Is it usable without background images turned on? (White text on a dark background gradient within a white page becomes white text on a white background with images turned off.) Can a user with images turned off complete key tasks?
- Unobtrusive JavaScript. Unobtrusive JavaScript or progressive enhancement is still the holy grail of web development for most front-end developers. While it may be impractical (due to timelines or team skills), it is highly desirable. Whether it be for accessibility reasons or mobile support, ensuring that the major functions work without full browser JavaScript support is the sign of a well thought out implementation.
- Print it. Try printing a page to see how it prints. Does it get cut off? Is there a print style sheet being used? Some users still print regularly, and this test will give you an idea of the site’s abilities in another medium. Does your site pass the fold up and fit in your pocket test?
Using these 12 tests, how do your sites fare? Do they pass these simple tests? (Don’t worry if you fail a few, I certainly have in the past.) Use the results to improve your coding practices or change up your template testing before moving to rollout.
If you’re looking for some quick insight into certain areas, try these test sets:
- Quick Acid Test: Include tests 1, 2, 3, 4 and 8.
- Accessibility Test: Include tests 2, 3, 5, 9, 10 and 11
- Performance Test: Include tests 1, 3 and 7
How about you? Do you have any quick and easy tests for evaluating CSS or a markup implementation?
