Homegrown CSS Standards
The following is a brief outline of a few tips, tricks, and personal preferences for standardizing your HTML/CSS websites and web applications. These suggestions have been pulled from personal experience and tend to fit 99% of the projects I’ve been involved in. Remember, even though I’m calling them standards, there are always exception, so don’t simply mimic any set of standards — evaluate the situation and apply the most appropriate solution.
Good Foundations
It is generally easier to begin style implementation with div’s. A CSS-based HTML design typically will have appropriately used div’s to section off major groupings of HTML data. For example:
…
<body>
<div class=”container”>
<div class=”header”>
<h1>My Example HTML</h1>
</div>
<div class=”nav”>
<ul>
<li>Microsoft</li>
<li>Yahoo</li>
</ul>
</div><div class=”content”>
<h2>My Example Subheader</h2>
<p>Some lorem ipsum goes here…</p>
<p>And now a bit more…</p>
</div>
</div>
</body>
…
As you can see, there are no tables being used for design purposes, table should generally be used for tabular data and not design layout. HTML with heavily used tables limits the ability for design to be fully manipulated by a CSS style sheet.
Now that we’ve written HTML that is geared to a CSS-based design, we can use the “hooks” we created to manipulate the CSS however we need and it will be readable for both an HTML designer/developer and a CSS developer.
For an example of design being completely dictated by CSS see CSSZenGarden for more. The HTML is always the same and only the CSS file changes in each example.
HTML that is developed in Visual Studio under the default validation settings for HTML will provide warnings/errors of invalid or inappropriate HTML. Please heed these warnings to provide the cleanest amount of HTML to work from. This is the foundation of any web application and for all other aspects such as CSS, JavaScript, and even code-behind to function properly, HTML should be sound. After all warnings have been addressed through Visual Studio, take time to also validate the HTML in an HTML Validator provided by W3 Consortium.
CSS File Organization
When developing a hierarchy of style sheets, separate styles into common and specific categories, then create a common.css file to store all common styles and individual specific CSS files for other major collections of CSS styles. See below example:
If I have a website that consists of three major portals, Public, Vendors, Administration; I would most likely create four CSS style sheets; one for each major portal, as well as one common.css file for common styles used in all portals.
Example: Use of Multiple Cascading Style Sheets
Common.cssa img
{
border: none;
}Public.css@import url(“common.css”);body
{
background-color: #CCC;
}Vendors.css@import url(“common.css”);body
{
background-color: #AAA;
}Administration.css@import url(“common.css”);body
{
background-color: #FFF;
}
This allows us to gain the true benefits of “cascading” style sheets, as each style sheet is importing and thus inheriting (or overloading, when appropriate) the parent style sheet(s).
Use discretion as to the number of CSS files to import against. In most cases, there is only need for a single import per CSS file. Several imports can become unwieldy and difficult to track down CSS class inheritance.
CSS Formatting
When adding CSS styles to a CSS style sheet, format the document in the following general sections:
Import CSS file(s)
HTML overloads
Custom CSS styles
Example: External CSS Sample
Example.css
import url(“common.css”);body
{
background-color: #FFFFCC;
}input, textarea, select
{
background-color: #FFFFAA;
}/*Content found within the main content placeholder.*/
.content
{
padding: 15px;
}/*Main navigation section.*/
.nav
{
border: 1px solid #000;
}
.nav ul
{
list-style-type: none;
}
.nav ul li
{
margin-left: 10px;
margin-right: 10px;
}
All HTML overloads are located first and grouped together, and custom styles make up the rest of the document. Notice, that all custom styles have comments as to what they affect to assist in maintaining changes. HTML overloads can have comments as well, but are not really necessary. Additionally, styles either as HTML overloads, or custom, that are cascading within a document should be grouped together without vertical spacing as demonstrated with “.nav”. Please note that there are no CSS styles applied to ID elements! These are commonly used as follows:
Example: CSS Style Based on Element ID
#nav
{
padding: 15px;
}The reason for this is that we want only class declarations in the HTML because it specifically tells the HTML observer (developer) that this object/tag has a CSS style applied to it, whereas the use of CSS against an ID tag does not convey this. When CSS is complex and uses repositioning or floats, etc. this can become very difficult to identify where HTML issues are occurring verses applied CSS. ID tags in HTML should be used for identification of objects/tags (for use with javascript/codebehind, etc.) and not for CSS styling.
Miscellaneous Formatting
Use spaces to enhance readability such as the following:
Bad:
.nav{background-color:#000000;}
.header{
padding:10px;
}Good:
.nav
{
background-color: #000000;
}.header
{
padding: 10px;
}
Always terminate style attributes with a semi-colon, even when there is only one style attribute being applied.
Explicitly write out style attributes for less-common or hard to read attribute values instead of combining them into a single line:
Example(s): Readability
Bad:
padding: 10px 5px 10px 5px;Good:
padding-top: 10px;
padding-right: 5px;
padding-bottom: 10px;
padding-left: 5px;
Additionally, when managing page layout widths, adjust widths from the highest containing item possible rather than specific nested objects. See the following HTML/CSS example:
…
<body>
<div class="container">
<div class="header">This is the header!</div>
<div class="nav">
<ul>
<li>Link 1</li>
<li>Link 2</li>
</ul>
</div>
<div class="content">
<p>Here is some content.</p>
</div>
</div>
</body>
…CSS:Bad:
.header
{
width: 780px;
}.nav
{
width: 780px;
}.content
{
width: 780px;
}Good:
.container
{
width: 780px;
}
CSS Style Naming
Some common things to remember while naming styles:
- Avoid using names which are too specific to the styles being applied, for example: “bluetext” or “leftNav”. Today you may be developing the text to be blue, or the navigation to be on the left, but tomorrow the text may change to green and the navigation may be right or top of the page.
- Use consistent naming convention: Florida Family will be using camel case (“mainNav” or “nav”).
- Don’t use acronyms or uncommon abbreviations such as “hlsm” (highlighted sub-menu).
- Attempt to keep names fairly short, generally less than 15 characters.
- Do not prefix CSS styles with “css” such as “cssNav”.
CSS Validation
Don’t forget, it’s never a bad idea to validate your CSS (W3 CSS Validator)!
Thanks for reading, I hope this makes life a little easier when working with your HTML/CSS projects!
