In the 90’s and 00’s, programmers used to scorn front-end designers who called writing HTML “programming.” That changed when CSS arrived and pixel-perfect results raised the bar.
Here’s some tips for programmers struggling with fixing CSS rendering problems:
Before Getting Started
- Treat a CSS project like learning a new programming language. Schedule a day when you’re fresh. You will need all of your concentration ability if you’re new to CSS because of the nested inheritance and browser quirks. If you finish early, that’s a nice bonus.
- You may want to capture screenshots of what the original site looks like. The Mac OS X Preview app has professional-looking annotation features by Adobe under “Tools … Annotate.”
- make a backup of the old CSS directory and save in a safe place. Then copy the CSS into a subdirectory so you can use the diff command on the old and new versions
- if your site uses normalize.css, ensure it’s the most recent version, especially before mobile testing.
- ensure your network environment has isolation: no load balancers, proxies or far future expires that can cache your old CSS files while testing
- use the W3C HTML and CSS validators to get a feeling for what’s there and pair each div with /div (I helped debug the original HTML validator.) 🙂
- use browser developer tools to examine the CSS. My favorite is Firefox’s Inspector.
- remember the hierarchy with CSS:
- the most-specific style wins
- the last definition wins, whether at the block or file level
- pseudo-classes: “Note: a:hover MUST come after a:link and a:visited in the CSS definition in order to be effective! a:active MUST come after a:hover in the CSS definition in order to be effective! Pseudo-class names are not case-sensitive.”
- !important wins. (Try to avoid this unless for example you’re fixing a browser z-order rendering problem.)
- all bets are off with syntax errors, missing semicolons, or mis-specified class name lists, so fix those first. See below.
- do some reading online about block and inline element display. Some properties can only be applied to a block element, which usually means adding an enclosing div.
- CSS uses the original C-style comments of slash-star. Invalid comment characters, like // and #, can cause surprising behavior. Firefox will log “Selector expected. Ruleset ignored due to bad selector.”
Note: if you’re paying for HTML or CSS, always validate it before payment. Even better, ask your designer to validate it weekly and before delivery.
- verify if there are any CSS media screen blocks that vary with resolution
- verify the correctness of individual class definitions, especially lists. if “cascading seems broken”, most likely there is a syntactically-correct but stray ‘div’, ‘p’ or ‘input’ after a class name
- once the CSS looks sane, you can debug problems by setting enclosing div classes to red or green and refresh your browser
- if there’s multiple CSS files included, try varying the order
- to debug rounded corners issues, try setting the background to black or white for maximum contrast
- test on Firefox, Safari, Chrome and IE11. Budget twice as much time if you want to support IE9 and IE10
- try overriding a CSS element or enclosing div with an inline style to narrow down a problem.
If you’re on a deadline or don’t have story points for a CSS project, there are workarounds.
- Although it’s better to write classes that apply to all elements, being more specific can fix individual form field problems
- As a temporary fix, doing an inline style will guarantee what the element looks like.
- if you’re not working solo, use the diff command to communicate changes to other developers and artists
- coordinate the checkin. Note that artists often are not version control experts, so you need to find out what the natural flow is or somebody’s changes will get stepped on (seen it twice already.) Investing some time now could prevent big problems later
- maxlength doesn’t work on input type=number
- it’s more difficult to left-justify and right-justify 2 items in CSS than with tables