CSS Web Design

Basic Tips

• Underlying HTML code structure should be semantic and clean.
• Look for repeated patterns, identify standard chunks of content by similar function and structure. Standardize HTML tags and class names used for these elements. Think in terms of basic reusable building blocks. Try to keep HTML structure and CSS naming schemes semantically-based but include plenty of “hooks” for flexible skinning options.
• Separate CSS styles into two main groups—layout and design. The layout styles are the default styles which will be applied to all skinnable pages. These set up the basic structure and should be bullet-proof. Extensive cross-browser testing is vital. The second group of styles sets the design or “skin”. These consist of fonts, font colors, background colors and images, etc. To change the skin, just create different skin CSS files and swap them out. Creating new skins can either be done by writing skin CSS code from scratch or set up a WYSIWYG system to apply different visual styles (backgrounds, borders, etc.) to the standard building blocks of your web page and generate a CSS file automatically.

Text/Fonts

Use Browser rendered text whenever possible rather than image-based text.

Advantages to browser-rendered text:

• Text is easier to edit and update.
• Increases usability: users can increase text size if needed, etc. to make it easier for them to read.
• Can improve search engine accessibility.

Browser-safe fonts:

See this site for a comprehensive list of fonts common to both Windows and Mac users:
http://www.ampsoft.net/webdesign-l/WindowsMacFonts.html

Facebook’s default fonts:
Lucida Grande, Tahoma, Verdana, Arial, sans-serif
Default font size: 11 pixels

If a font isn’t specified for an app these fonts will be used by default in order of availability. (If a user doesn’t have the first font in the list installed on their computer, the next available font in the list will be used and so on.)

Note: “Lucida Grande” is installed on most Macs but few Windows users have it so they will likely see Tahoma instead.

Font sizes:

For best readability, main body copy should generally be at least 11 pixels or larger (10 pixels as an absolute minimum). 9 pixels can be acceptable for less important text like copyright info but it’s preferable to keep all text sizes at 10px +.

Tab/App Content Dimensions

Facebook is re-designing Fan Page tabs in the future to be 520 pixels wide (reduced from current 760 pixels wide). So to maintain compatibility with this upcoming change designs should be created with this in mind. The 520 pixel width includes all content appearing within a tab so for example if your design includes content in a box with a drop shadow, the drop shadow needs to fit within the 520 pixel page width.

Place important content “above the fold”

Avoid making users have to scroll too much to see content you want to highlight. Measuring from the top of the Tab canvas area, your most important content should ideally fit within about the first 430 pixels in height.

Don’t re-create your Web site

In general, it’s best to keep Tab designs relatively short and simple with clear calls to action. Avoid creating mini web sites with multiple sub-pages within one tab or extra long designs that require users to scroll too much to view all content. Facebook users can have short attention spans so focus designs on the information or functionality you most want them to see and use.

• Apply margins or padding to containers rather than to individual elements. This makes it easy to keep margins consistent and to easily update later if needed.
• When looking at a design, look for repeated elements and structures. Think about the most basic functions of these structures when coming up with class naming schemes.
• Look at the functions of elements from general to more specific. For example, a design may include several types of “notices” such as for errors, warnings, and success messages. The design of these notices should be the same except for colors for example. So use a general classname for the basic “notice” styles together with a second classname for the type of notice that sets the colors.
• Use basic semantic HTML tags. If you use semantic tags properly it’s not necessary to give everything a classname in order to distinguish seperate elements and your HTML documents will be more accessible and search-engine friendly.

• Mixes presentation with content. (not semantic)
• Can’t be over-ridden with CSS. (not easily and reliably anyway)
• No control over amount of space it adds.

So how should you use break tags?

Break tags should only be used inside a block level element such as a paragraph or header in order to break a line of text. Never use them to add space between elements. Use CSS styles instead.

CSS frameworks such as the 960 Grid System can be helpful in creating complex multi-column magazine-style page layouts. A major drawback of these frameworks however is that they are mainly presentation-based instead of being semantic-based. In addition they can be overkill when all you want to create is a fairly simple layout with just a few types of columns (The 960 Grid System for example is based on 12 and 16 column grids).

The Pretty Semantic CSS Framework is an attempt to address some of these issues. The Pretty CSS Framework works together hand in hand with the Pretty Semantic HTML Template. The HTML template uses HTML5-based elements such as “header”, “nav”, “section” and “footer” (div tags with class names are used for browser compatibility). It does use some column divs with presentation based names which is what makes it only “pretty” semantic. There are only a few basic column widths defined however which should work fine for most not overly-complex layouts. (Columns are based on halves, thirds and fourths.)

After using Pretty to lay out your page, you can replace the few presentation based column class names with more semantic class names that fit your content such as “sub-nav”, “main-col”, “supporting-col”, etc.

Pretty Semantic CSS

The CSS includes only the basic minimum styles needed for creating rough layouts. The page is based on a 960px width. No general CSS reset is included although some elements within the header, footer and nav have resets. The reason for not including a reset is that in my opinion they can be overkill in some instances when applied automatically to all content. For pages containing a lot of plain text content it’s often more efficient to make use of some default browser rendering of things like paragraph and header margins. Feel free to add a reset if that works best for your design.

Pretty Semantic HTML Template

The HTML template gives examples of how to use the basic class names included in the Pretty Semantic framework in order to structure your page and create the basic rough layout. Delete any parts you don’t need or re-arrange elements to suit your design. Example navigation links are placed inside their own labeled div in the template as an example. This separate nav div could be deleted and the the UL containing the class links could instead be given the “nav” class name and then moved inside the header div with new styles applied as one possible option.

Download Files

Zip of all files: http://www.kristinbradley.com/pretty-semantic-css.zip

After downloading the code you can paste it in here to test it out: http://www.webcodeshare.com

NOTE: This is just the 1.0 release of the framework. So far it’s been tested in FF3.0.16, IE6 and IE7. Please feel free to make suggestions for improvement and let me know of any bugs you find.