HTML and CSS Reference
In-Depth Information
Disable Hacks
Hacks, while usually very focused (especially those discussed in Chapter 6 and throughout this
book), are still capable of causing some problems, especially in the browsers they target (typically
IE/Win, but not always). If you are having problems with a browser that is targeted by some of
your hacks, disable them and see if your troubles remain (yet another reason to keep your hacks
in separate style sheets; commenting out or temporarily deleting a <link> or @import is much
easier than removing hacks from your main style sheet).
Create Minimal Test Cases to Simplify Problems
If a problem is proving to be considerably vexing, creating a simplified version of the markup
and styles (known as a reduction or “minimal test case”) allows you to confirm whether you
are running into a browser bug or an error in your (X)HTML/CSS.
The cascading nature of CSS often results in compound problems, unwanted effects
resulting from more than one rule or declaration combining in unexpected ways. Simplifying
the associated markup and styles helps rule out possible causes, similar to disabling styles as
we discussed earlier.
There is no simple example to give, because by definition something that needs to be reduced
to its most simple form must be complex to begin with, and would be impractical to display on
these pages. And there is usually no pattern to the problems that require reduction (once you've
solved a complex problem, you can recognize it more easily the next time you encounter it).
Like the method of disabling styles, creating a minimal test case is all about logical
simplification of the affected elements (both markup and styles). For instance, if you think
items in a list are being affected by combined styles, create a test document containing only
the list and its related styles and see if the problem remains. If it does, your error is within the
reduction—solve it and update your main styles and markup; if things look as intended,
slowly add the surrounding markup (and styles), testing with each addition until the problem
resurfaces, at which point you can begin to narrow down the possibilities.
This approach can be time consuming, but the more complex your styles and markup
become, so too does the process of debugging them.
Common CSS Mistakes
We've all been there at some point: that long night of testing, spending hours trying to squash
a bug in your layout, having no success with anything, only to discover (finally) that it was
a simple error. On your part. Nothing feels quite like that moment of discovery and realization
that those wasted hours could have been avoided if only you hadn't made the mistake to begin
with. We've done it, you've done it, and we can pretty much guarantee that it'll happen to each
of us many more times over our lifetime.
Now, while we'd love to explain to you how to never make a mistake again ever , reality has
other plans, so instead we'll shoot for a few of the more (or less) obvious examples of human
error that frequently trip up developers.
Search WWH ::




Custom Search