HTML and CSS Reference
In-Depth Information
</head>
<body>
<p>The content of our page.</p>
</body>
</html>
base.css:
@import url("layout.css");
@import url("typography.css");
Here, our linked style sheet,
base.css
, imports two additional style sheets,
layout.css
and
typography.css
. We've split our CSS into three separate files, but the browser will treat them as
if they were one long style sheet.
Personal preference is involved in deciding which is easier to wrap your brain around—
one file or multiple files. Oftentimes, the scope of the project will dictate your methodology.
A small project with only a few pages may have far fewer styles, and thus be quite manageable
in a single file. Larger projects are more likely to get complex, and breaking their style into
multiple files may help you keep track of things more efficiently. You also may find special
cases that warrant their own style sheet, such as groups of hacks and workarounds to com-
pensate for browser bugs or styles specifically for a particular media type (such as
print
or
handheld
).
Whether you decide to break up your styles into multiple files is entirely up to you. With
a little experimenting, you'll find methods that make sense for you and your team.
Conventions for class and id Names
Another common point of debate among CSS pedants is the style in which you write your
CSS
class
and
id
names. Many CSS writers are familiar with programming languages of vari-
ous types, so it's natural for them to use conventions similar to those they're familiar with. The
Python language, for example, encourages the use of the underscore (
_
) character for variable
names with more than one word (for example
comment_form
or
main_content
.) JavaScript pro-
grammers tend to use what's commonly referred to as “camel case”—in which the first letter of
any word(s) after the first one is capitalized (like
commentForm
and
mainContent
). Still other people
prefer the hyphen (
-
) character to separate words (
comment-form
or
main-content
).
CSS itself is not particularly picky. Any of these notations are valid, and it's up to you to
choose the one that works best for your workflow. If your developers commonly work in another
language, it may be wise to pick a convention similar to the one that language prefers. You
may want to consider readability when you choose (it can be argued that the underscore
makes for the most readable names). And finally, you may wish to consider ease of typing; for
example, using the hyphen character prevents you from having to press the Shift key, as you
would have to when producing an underscore character or capital letter. This can be more
efficient, especially in reducing typos.
As with most of the suggestions in this chapter, what you choose isn't as important as
taking the time to make a conscious choice.
