- Applying CSS to the page
- Styling the basic and enhanced experiences
- Accessibility considerations
- Dealing with bugs and browser inconsistencies
This chapter is from the book
This chapter is from the book
This chapter is from the book
Styling the basic and enhanced experiences
When referencing external CSS with our test-driven PE approach, there are additional considerations to be made. Since our capabilities testing framework allows us to provide both a basic and an enhanced presentation of the same page, we need to decide which portions of the CSS should be sent to everyone, and which portions should be reserved for users with more capable browsers.
The testing framework allows us to make a very clean division between the CSS that's delivered to all browsers (including those that fail any part of the capabilities test suite) and browsers that pass all test criteria. For the sake of clarity in the examples that follow, we'll assume that the styles for each experience are going to be stored in separate style sheets named basic.css and enhanced.css. Any styles included in basic.css will be referenced in the page source when it's first served, and if the browser passes our capabilities tests, we will then load enhanced.css into the page as well. (We'll detail the mechanisms for referencing these CSS files using the framework in Chapter 6, "Testing browser capabilities.")
Safe styles for the basic experience
Most browsers have a default style sheet that does a good job of communicating content hierarchy with these defaults, so we generally let the browser's style sheet take precedence and override it as little as possible. In our experience with test-driven PE, we've discovered that a number of "safe" CSS properties are OK to use in the basic experience, so we typically set these in our basic.css style sheet. These properties will render fairly consistently across browsers that support any level of CSS, new and old—and while some browsers won't respect these properties, they won't break the site if they aren't recognized:
- Text formatting: The default fonts for a site can be set on the body tag with a font "stack" that lists the most preferred fonts first (font-family: "Segoe UI", Helvetica, Arial, san-serif); we recommend that the stack should include fonts that are commonly installed on many systems. Other text formatting, such as bold (font-weight: bold), italic (font-style: italic), strikethrough (text-decoration: line-through), capitalization (text-transform: uppercase), alignment (text-align: center), leading (line-height:1.2), and tracking (letter-spacing: 0.3em) are all fairly well supported by most browsers. (We recommend not setting font sizes, or changing the text-decoration property to modify the default underline on links, in the basic experience.)
- Text color and backgrounds: In general, text color (color: red), background colors (background-color:#224466), and background images (background-image: url(images/texture.png)) are safe to use in the basic experience, as long as the text is legible when background image or color is not applied. Keep in mind that some mobile browsers support text color but not background color, so that reversed-out text (light text on dark background color, for example) may not be visible. Also, it's important to note that many mobile browsers will always render linked text in blue, so you could end up with blue text even if you specify a legible link color. (If the background were dark blue, links could be completely invisible.) As a rule of thumb, we recommend reserving reversed-out text for the enhanced experience.
- Padding and margin: When used very sparingly, padding (padding:1em) and margin (margin-top:1.5em) can space elements apart and enhance the readability of a page in the basic experience . Floating, positioning, stacking, or setting negative margins, dimensions, or overflow properties should never be set in the basic style sheet.
- Border: Used in moderation, borders (border:1px solid black) can draw attention to groups of content, and greatly improve the basic experience.
Combined, these style properties are often sufficient to add light branding to a site to make it unique and recognizable, and to enhance user-friendliness.
There is one additional advantage in keeping basic.css very simple and clean: it may be able to function as both the basic screen experience and a print style sheet. To do this, be sure to add a print-specific @media block to basic.css that hides any elements in the enhanced experience that would be irrelevant when printed (navigation, advertisements, etc.):
@media print {
h1 { font-size: 16pt; }
h2 { font-size: 14pt; }
h3 { font-size: 12pt; }
#navigation, #advertisement { display: none; }
}
Styling the enhanced experience
By using capabilities testing to send our enhancements only to browsers that will understand them, we can apply advanced CSS layout techniques—like floats, positioning, and more—with confidence that they won't cause usability problems. This practice also allows us to write enhanced CSS that assumes JavaScript is available and well supported.
There are a number of best practices we follow when writing enhanced CSS that we recommend considering:
- Let CSS do the work. When a page component has multiple, dynamic visual states that react to the user's input or manipulation (such as default, highlight, or disabled states), write a class for each state and toggle it on/off using JavaScript. This lets CSS do the heavy lifting, and prevents situations where unnecessary inline styles are added with JavaScript.
- Embrace the cascade. If a basic CSS is written with a light hand, the enhanced CSS can cleanly extend it without having to negate any styles that were already declared. This is why we advocate using very little CSS in the basic experience.
- Keep resets minimal. If your enhanced CSS rules depend on reset styles that normalize or negate the browser's default styles, we recommend including them at the top of enhanced.css (and avoid using them altogether in basic.css). We highly recommend resetting as few styles as possible, and building on top of the styles provided by the browser. This is especially important with form elements, which have certain default styles that users will recognize, and it's best to leave them intact whenever possible.
- Adopt forward-looking CSS when possible. A number of newer CSS3 features that allow for rich visual styling—like rounded corners, drop shadows, variable opacity, and animated transformations—are gaining support in the latest browsers, can reduce code bloat, and provide more powerful selectors for associating style rules with markup structure. For example, using CSS3 border-radius to round the corners of an element eliminates the need to use several HTML elements to hold background images for each corner of a box. While many of these features will not work in older browsers like IE6, they are safe to use in enhanced experiences, because they'll be ignored in browsers that don't understand them.
- Be mindful of setting type with images. A design may call for a custom font that isn't commonly installed on computers and devices. We never recommend setting type in images (even when applied with accessible techniques, like alt attributes). There are many custom font techniques that ensure that page content is available to all users (including those on screen readers) and make it possible to provide the site content in various languages. Custom type can be rendered in Canvas or Flash to visually replace portions of a page's text, and many browsers also support CSS @font-face to reference custom fonts by URL.