- The Web Environment
- Determining Your Cross-Browser Goals
- Developing Your Site for Different Devices
- In Conclusion
This chapter is from the book
This chapter is from the book
This chapter is from the book
Developing Your Site for Different Devices
As we have found out already, browsers have varied support for CSS features. Another difference in browsers is in how they display HTML text and white space that doesn’t have any CSS customization. The underlying browser styles can influence the CSS presentation layer, so we try to take the browser styles back to a basic and common foundation.
Resetting and Normalizing Browser Styles
Browsers have their own internal style sheets, which designers use to render basic default styles for everything from the distance between lines of text to link colors (Figure 4.13).
)
Figure 4.13. Differences in Internet Explorer 9 vs. Firefox browser rendering on Windows.
Resetting Styles
One way to address browser inconsistencies is to remove or set all CSS properties to zero. This is done through a CSS style sheet known as CSS Reset, like the one premade from Yahoo! through its YUI Library. To set up a reset for a web page (Figure 4.14), place a link element at the top of any other reference to the style sheet (Figure 4.15):
<link rel="stylesheet" type="text/css"href="http://yui.yahooapis.com/3.7.1/build/cssreset/cssreset-min.css"><link rel="stylesheet" type="text/css" href="style.css">
)
Figure 4.14. Before the CSS Reset.
)
Figure 4.15. After the CSS Reset.
Normalizing Styles
Using the CSS Reset approach means that all default settings are dialed back. What’s left is an empty canvas with no hint of design or standards. That’s where normalize.css steps in. Rather than removing everything, Normalize.css (http://necolas.github.com/normalize.css/) creates a cohesive standard for the default rendering of HTML elements (Figure 4.16).
){kind=link}
)
Figure 4.16. After normalize.css.
Normalizing style sheets gives you a solid base to build web pages without having to worry about little discrepancies in browser renderings.
Vendor Prefixes
Sometimes a new CSS feature brought into a browser is still in its beginning stages and needs more work. When this happens, the browser vendor usually provides what’s called a prefix CSS property.
The Simple CSS Workaround
For example, a simple CSS gradient like the following code will be ignored in Safari 6:
div {
background-image: linear-gradient(#fff, #000);
}
To get Safari to work, we have to add a line of code that only Safari will recognize:
div {
background-image: -webkit-linear-gradient(#fff, #000);
background-image: linear-gradient(#fff, #000);
}
The software that powers the rendering or display of a page in Safari is known as WebKit. Therefore, to specify a special feature like a gradient, we need to add “webkit” surrounded by hyphens. To support other browsers that have the same approach to new CSS features, we need to add the special vendor prefix for each of them (TABLE 4.3):
div {
background-image: -webkit-linear-gradient(#fff, #000);
background-image: -moz-linear-gradient(#fff, #000);
background-image: -ms-linear-gradient(#fff, #000);
background-image: -o-linear-gradient(#fff, #000);
background-image: linear-gradient(#fff, #000);
}
Table 4.3. WebKit Vendor Prefixes
|
Browser |
Vendor prefix |
|
Safari |
-webkit- |
|
Firefox |
-moz- |
|
Internet Explorer |
-ms- |
|
Opera |
-o- |
Automatic Vendor Prefixing
For one CSS feature in our text shadow example, five additional lines of code were needed to support browsers. If we need to add additional lines of code for each browser for each new CSS feature, the lines of code we generate would quickly get out of control. Web developer Lea Verou realized the vendor prefixes situation and developed a piece of JavaScript called -prefix-free (http://leaverou.github.com/prefixfree/), shown in Figure 4.17:
)
Figure 4.17. The -prefix-free homepage.
By downloading the file and placing the -prefix-free JavaScript file in the head element of your web page, the vendor-prefixes are automatically applied to the user’s browsers if they need them:
<head>
<meta charset="utf-8">
<title>My Web Page</title>
<link rel="stylesheet" href="style.css" />
<script src="prefixfree.js"></script>
</head>
That means you can focus on writing clean code and not worry about double-checking browser support features in the CSS.
Validation
Once you’re satisfied with your design, you’ll want to validate your HTML and CSS code to make sure it complies with all the requirements and rules that we’ve established thus far. A validator is a tool that checks the code for proper HTML and CSS syntax by making sure that all tags are closed and properly nested. If there are no syntax errors, then the page is said to validate.
More than likely your pages won’t validate the first time you code them—it’s surprisingly easy to forget a tag or a quote. Luckily the validators are specific as to what the error is and where it’s located (Figure 4.18):
){kind=link}
)
Figure 4.18. Validator reporting errors.
At first, validating your code may seem impossible, but it becomes easier as you get used to what clean, syntactical code looks like. The W3C has a markup validation service at http://validator.w3.org/unicorn/. Simply upload your document or provide its address, and the validator quickly gives you a report on both HTML and CSS errors. Working through the validator can be a little puzzling at times because of the error messages, but once you clean up any errors you get a clean bill of health (Figure 4.19).
)
Figure 4.19. Gaining the coveted seal of approval from a validator.
Another valuable tool is HTML Tidy (http://infohound.net/tidy/). This tool actually fixes badly formed markup: it adds closing tags, changes mismatched tags, adds quotes to attribute values, and properly nests tags that are not nested (Figure 4.20). Stand-alone tidy applications are available for various platforms, and there are online versions as well. HTML Tidy also comes with many HTML and text editors.
)
Figure 4.20. HTML Tidy makes your code cleanly spaced and balanced.
Testing
When designing for the web, it’s important to test against as many browsers and devices as possible. It can be difficult to maintain a number of desktop browser installations—both new and older—and get your hands on a wide range of devices to create a full mobile testing suite. Here are some suggestions to make cross-device development a little less complex.
Software
Use services like BrowserStack (http://www.browserstack.com/) to quickly test different platforms, browsers, resolutions, and connection speeds (Figure 4.21).
)
Figure 4.21. Using the Browser-Stack interface to check out a page design.
If you own a Mac, buy a software package like Parallels (http://www.parallels.com/products/desktop/) or VMware Fusion (http://www.vmware.com/products/fusion/overview.html). You can download Oracle VirtualBox (https://www.virtualbox.org/) for free (Figure 4.22). These software packages allow for virtualization—running Windows and Windows-based browsers on a Mac. You’ll still need to purchase a Windows OS license, but you won’t have to buy a separate machine.
)
Figure 4.22. Oracle VirtualBox.
Hardware
After creating a test page, upload it to the web and then take a breather. Go to your local computer store and check out your web page design in the store’s display models. Check in on cell phone stores, too, to see how your page looks in their mobile devices.
If you can, buy a smartphone on eBay or ask friends and colleagues for their old phones and devices when they upgrade. You might be surprised how many people have old devices hanging around in a junk drawer. When you upgrade to a new device, keep your old one around for testing to create your own mini testing lab. Use services like Adobe Edge Inspect to test web pages on different devices. MobileTh.at is a new service, just being coded at the time of writing, that promises to simplify mobile testing.