Part I: Getting Started 26 Putting It All Together When I first began writing HTML, it helped me to think of the tags and text as “beads on a string” that the browser deals with one by one, in sequence. For example, when the browser encounters an open bracket (<) it assumes all of the following characters are part of the markup until it finds the clos- ing bracket (>). Similarly, it assumes all of the content following an opening <h1> tag is a heading until it encounters the closing </h1> tag. This is the manner in which the browser parses the HTML document. Understanding the browser’s method can be helpful when troubleshooting a misbehaving HTML document. But where are the pictures? Obviously, there are no pictures in the HTML file itself, so how do they get there when you view the final page? You can see in Figure 2-3 that each image is a separate graphic file. The graphics are placed in the flow of the text with the HTML image element (img) that tells the browser where to find the graphic (its URL). When the browser sees the img element, it makes another request to the server for the image file, and then places it in the content flow. The browser software brings the separate pieces together into the final page. The assembly of the page generally happens in an instant, so it appears as though the whole page loads all at once. Over slow connections or on slower computers, or if the page includes huge graphics, the assembly process may be more apparent as images lag behind the text. The page may even need to be redrawn as new images arrive (although you can construct your pages in a way to prevent that from happening). Putting It All Together To wrap up our introduction to how the Web works, let’s trace the stream of events that occur with every web page that appears on your screen (Figure 2-4). You request a web page by either typing its URL (for example, http://jen- skitchensite.com) directly in the browser, or by clicking on a link on the page. The URL contains all the information needed to target a specific document on a specific web server on the Internet. Your browser sends an HTTP Request to the server named in the URL and asks for the specific file. If the URL specifies a directory (not a file), it is the same as requesting the default file in that directory. The server looks for the requested file and issues an HTTP response. If the page cannot be found, the server returns an error message. The message typically says “404 Not Found,” although more hospitable error messages may be provided. 1 2 3 a. Putting It All Together Chapter 2, How the Web Works 27 4 The browser parses the document. If it has images, the browser contacts the server again for each graphic file. 5 The page is assembled in the browser window. H T T P r e q u e s t H T T P r e s p o n s e 2 The browser sends an HTTP request. Server Oops, no file If the file is not on the server, it returns an error message. Server Contents index.html Browser 1 Type in a URL or click on a link in the browser. 3 The server looks for the file and responds with an HTTP response. “I see that you requested a directory, so I’m sending you the default file, index.html. Here you go.” masthead.gif spoon.gif index.html masthead.gif spoon.gif Figure 2-4. How browsers display web pages. If the document is found, the server retrieves the requested file and returns it to the browser. The browser parses the HTML document. If the page contains images, (indicated by the HTML img element), the browser contacts the server again to request each image file specified in the markup. The browser inserts each image in the document flow where indicated by the img element. And voila! The assembled web page is displayed for your viewing pleasure. b. 4 5 Part I: Getting Started 28 Test Yourself Test Yourself Let’s play a round of “Identify that Acronym!” The following are a few basic web terms mentioned in this chapter. Answers are in Appendix A. HTML a) Home of Mosaic, the first graphical browser W3C b) The location of a web document or resource CERN c) The markup language used for all web documents HTTP d) Matches domain names with numeric IP addresses IP e) A limited set of letters, numbers and symbols URL f) Internet Protocol NCSA g) Particle physics lab where the Web was born DNS h) Protocol for transferring web documents on the Internet ASCII i) The organization that monitors web technologies Answers: ____________________________________________________________ 1. 2. 3. 4. 5. 6. 7. 8. 9. 29 IN THIS CHAPTER How variables on the user’s end affect the way your page looks and performs, including: Browser version Alternative browsing devices User preferences Platform Connection speed Browser window size and monitor resolution Monitor color As a web designer, you spend a lot of time creating pages and tweaking them until they look good in your browser. Before you grow too attached to the way your page looks on your screen, you should know that it is likely to look different to other people. That’s just the nature of web design—you can’t guarantee that everyone will see your page the way you do. The way your site looks and performs is at the mercy of a number of variables such as browser version, platform, monitor size, and the preferences or special needs of each individual user. Your page may also be viewed on a mobile device like a cell phone, or using an assistive device like a screen magnifier or a screen reader. This unpredictable nature of the Web is particularly challenging if you have experience designing for print, where what you design stays put. As a print designer who made the transition to web design, I found I needed to let go of controlling things such as page size, typography, and precise color. Having a solid understanding of the web environment allows you to anticipate and plan for these shifting variables. Eventually, you’ll develop a feel for it. This chapter looks at the ways in which browsers, user configurations, plat- form, connection speed, computer monitors, and alternative browsing envi- ronments affect the design and functionality of web pages. It suggests some tips for coping along the way. Browser Versions One of the biggest challenges in designing for the Web is dealing with the multitude of browsers in current use. Although the current version of Microsoft Internet Explorer running on Windows makes up the lion’s share (60 to 80% as of this writing), there are at least a dozen browser versions that web developers pay attention to, and hundreds more obscure or antiquated browsers still in use. See the sidebar, Browser Roll Call, for more information on relevant browsers. In the no-so-distant past, browsers were so incompatible that web authors were forced to create two separate sites, one for Internet Explorer and one for Netscape (the only two players at the time). Fortunately, things have THE NATURE OF WEB DESIGN CHAPTER 3 The nature of web design is that there is no guarantee that everyone will see your page the way you do. Part I: Getting Started 30 Browser Versions Browser Roll Call It is important that web developers be familiar with the browsers in current use. Although there are hundreds of browsers out there, only about a dozen make up 99% of browser usage. The A-list browsers in Table 3-1 offer solid standards support and represent the vast majority of web traffic. Older and niche browsers listed in Table 3-2 may be tested to be sure that the content is available and accessible, but there is no effort made to reproduce the A-list browsing experience on these browsers. It should be noted that the browsers listed here, and the Usage Statistics in particular, reflect the browser landscape as of the writing of this book. Things are sure to be different by the time you are reading this. For updated browser statistics, go to www.thecounter. com or www.w3schools.com/browsers. Of course, the most meaningful statistics are those taken from your own site. 3% of visitors to your blog and 3% on a site like Yahoo! are different sized crowds indeed, and may warrant different support decisions. Table 3-1. A-list browsers (generally tested for a consistent presentation and scripting experience) Browser version Platforms Released Stats* Notes Internet Explorer 7 Windows XP, Linux, Unix 2006 14% IE7 improves support for CSS2 and fixes many of the bugs in IE6. It’s share will eventually surpass IE6 Internet Explorer 6 Windows, Linux, Unix 2001 58% IE6 usage will decrease as IE7 is distributed. Internet Explorer 5.5 and 5 Windows, Linux, Unix 2001 (5.5) 1999 (5) 1% There are significant differences in the way IE5 and 5.5 supports CSS, requiring workarounds until these versions finally go away. Some develop- ers have already stopped supporting IE5 with the release of IE7. Mozilla Firefox 1.0 Windows, Linux, Unix, Macintosh 2005 12% Fast and standards-compliant, this is the recom- mended browser of the development community. Netscape 7 & 8 Windows, Linux, Unix, Macintosh 2002 1% Netscape once dominated; now it is barely a blip on the radar. Opera 8+ Windows, Linux, Unix, Macintosh 2005 1% Opera is popular in the development community for its small size and standards compliance. Safari 1.0 and 2.0 Macintosh OS X 2002 (1.0) 2005 (2.0) 3% Safari comes with OS X. Safari 2.0 offers the most advanced CSS support of any current browser. Safari 3.0 Macintosh OS X, WIndows 2007 2007 n/a In public beta as of this writing. Table 3-2. Older browser versions (tested only to make sure content is available and accessible) Netscape 4 Windows, Linux, Unix, Macintosh 1999 < .5% Netscape 4 has only partial support for CSS and other standards. It is represtentative of legacy browsers. IE 5 (Mac) Macintosh 2000 < 1% The best standards-compliant browser option for users who must still use Mac OS 9 Lynx (or other text only browser) old versions for Windows, Mac, Unix 1992 n/a A text only browser is useful for testing the accessi- bility of content on less-than-optimal browsers. * Usage statistics taken from TheCounter.com in April 2007. N o t e For a complete list of all browers, old and new, see browsers.evolt.org. For Further Reading The article “Graded Browser Support” by Nate Koechley at Yahoo!’s Developer Network aptly sums up the contemporary approach to browser support. Read it at developer.yahoo. com/yui/.articles/gbs/gbs.html Browser Versions Chapter 3, The Nature of Web Design 31 improved dramatically now that browsers have better support for web stan- dards established by the World Wide Web Consortium (W3C for short). The situation will continue to improve as older, problematic browser versions such as Internet Explorer 5 and Netscape 4 fade out of existence. Fortunately, nearly all browsers in use today support HTML 4.01 and XHTML standards, with only a few exceptions. That doesn’t mean that an (X)HTML document will look identical on all browsers—there may still be slight differences in the default rendering of text and form elements. That’s because browsers have their own internal style sheets that determine how each element looks by default. Instead, the new challenge for cross-browser consistency comes in the varying support of certain aspects of Cascading Style Sheets (CSS). Although most of the basic style sheet properties can be used reliably, there are still some bugs and inconsistencies that may cause unexpected results. Figure 3-1 shows how the same web page may be rendered differently based on the browser’s support of CSS. Coping with various browser versions How do professional web designers and developers cope with the multitude of browsers and their varying capabilities? Here are a few guidelines. Don’t sweat the small stuff. As a web designer, you must allow a certain amount of variation. It’s the nature of the medium. What is important isn’t that form input boxes are all precisely 15 pixels tall, but that they work. The first lesson you’ll learn is that you have to let go. Stick with the standards. Following web standards—(X)HTML for docu- ment structure and CSS for presentation—as documented by the W3C is your primary tool for ensuring your site is as consistent as possible on all standards-compliant browsers (that’s approximately 99% of browsers in current use). Internet Explorer 5 (Windows 2000) Because of IE5Win’s implementation of CSS, centering is broken, columns overlap, and the tabs run together. Firefox 1.5 This page appears as the author intended. Figure 3-1. The same web page may look different on different browsers. In this case, the problem is in inconsistent implementation of certain style properties by IE5 (Win). Fortunately, the percentage of web traffic using IE5 (Win) is down around 2% and shrinking with the release of IE7 in 2006. Internet Explorer 5 (Windows 2000) Because of IE5Win’s implementation of CSS, centering is broken, columns overlap, and the tabs run together. Firefox 1.5 This page appears as the author intended. Figure 3-1. The same web page may look different on different browsers. In this case, the problem is in inconsistent implementation of certain style properties by IE5 (Win). Fortunately, the percentage of web traffic using IE5 (Win) is down around 2% and shrinking with the release of IE7 in 2006. Part I: Getting Started 32 Alternative Browsing Environments Start with good markup. When an (X)HTML document is written in logi- cal order and its elements are marked up in a meaningful way, it will be usable on the widest range of browsing environments, including the old- est browsers, future browsers, and mobile and assistive devices. It may not look exactly the same, but the important thing is that your content is available. Don’t use browser-specific (X)HTML elements. There are markup elements and attributes out there that work only with one browser or another, a remnant from the browser wars of old. Don’t use them! (You won’t learn them here.) Become familiar with the aspects of CSS that are likely to cause problems. Using style sheets effectively takes some practice, but experienced devel- opers know which properties are “safe,” and which require some extra tweaks to get consistent results on all current browsers. Alternative Browsing Environments The previous section focused on issues relevant to graphical browsers used on desktop or laptop computers. It is critical to keep in mind, however, that people access content on the Web in many different ways. Web designers must build pages in a manner that creates as few barriers as possible to get- ting to information, regardless of the user’s ability and the device used to access the Web. In other words, you must design for accessibility. Accessibility is a major topic of discussion in the web design world, and a priority for all web designers. While intended for users with disabilities such as poor vision or limited mobility, the techniques and strategies developed for accessibility also benefit other users with less-than-optimum browsing expe- riences, such as handheld devices, or traditional browsers over slow modem connections or with the images and JavaScript turned off. Accessible sites are also more effectively indexed by search engines such as Google. The extra effort in making your site accessible is well worth the effort. Users with disabilities There are four broad categories of disabilities that affect how people interact with their computers and the information on them: Vision impairment. People with low or no vision may use an assistive device such as a screen reader, Braille display, or a screen magnifier to get content from the screen. They may also simply use the browser’s text zoom function to make the text large enough to read. Mobility impairment. Users with limited or no use of their hands may use special devices such as modified mice and keyboards, foot pedals, or joysticks to navigate the Web and enter information. • • Browsercam A good shortcut for checking how your page looks in a variety of browsers (without installing them all yourself ) is to use a subscription service like Browsercam.com. For a monthly fee, just enter the URL of your page, and Browsercam captures the screen image in every browser configuration you can imagine. Check it out at www.browsercam. com. It is not a substitute for testing performance (you can’t tell if the scripts are working), but it can catch style sheet and even markup issues. D e V e l O P m e n t t I P Accessibility vs. Availability Web accessibility guru, Derek Featherstone, draws an interesting and useful distinction between “accessibility” for users with disabilities and “availability” for users with alternative devices such as mobile phones. Read his blog entry at www.boxofchocolates. ca/archives/2005/08/25/accessibility- and-availability F O R F U R t H e R R e A D I n G Alternative Browsing Environments Chapter 3, The Nature of Web Design 33 Auditory impairment. Users with limited or no hearing will miss out on audio aspects of multimedia, so it is necessary to provide alternatives, such as transcripts for audio tracks or captions for video. Cognitive impairment. Users with memory, reading comprehension, problem solving, and attention limitations benefit when sites are design ed simply and clearly. These qualities are helpful to anyone using your site. The lesson here is that you shouldn’t make assumptions about how your users are accessing your information. They may be hearing it read aloud. They may be pushing a button to jump from link to link on the page. The goal is to make sure your content is accessible, and the site is as easy to use as possible. The mobile Web The increased popularity of the Web, combined with the growing reliance on handheld devices such as cell phones, PDAs, and palm-top computers, has resulted in web browsers squeezing into the coziest of spaces. Although most content accessible on mobile devices has been developed specifically for that type of browser, an increasing number of devices now include microbrowsers capable of displaying the same web content that you’d see on your PC. Microbrowsers are designed to accommodate limited display area, lower memory capacity, and low bandwidth abilities. Some have only basic HTML support and others support the current web standards. One limitation of handheld devices is screen size. Mobile displays are roughly only 240 pixels square, although some have dimensions as small as 128 pixels or as large as 320. That’s not much room to look at a typical web site. Mobile browsers deal with the limited screen size the best they can. Some shrink the page to fit by displaying the text content as it appears in the HTML source document, and resizing the images to fit the screen. Others simply allow hori- zontal scrolling. Figure 3-2 shows the Jen’s Kitchen page as it might appear in a microbrowser on a cell phone. Dealing with diversity The best way to accommodate the needs of all your visitors is to design with accessibility in mind. Accessible design not only helps your disabled visitors, but also those using the Web on the go or under any less-than-ideal condi- tions. You’ll also improve the quality of your content as perceived by search engine indexing programs. The W3C started the Web Accessibility Initiative to address the need to make the Web usable for everyone. They developed the Web Content Accessibility Guidelines (WCAG) to help developers create accessible sites. You can • • Figure 3-2. This is the Jen’s Kitchen web page from Chapter 2 as it might appear on a mobile device. (The image was taken using the Openwave Mobile Browser Simulator available at developer. openwave.com.) Figure 3-2. This is the Jen’s Kitchen web page from Chapter 2 as it might appear on a mobile device. (The image was taken using the Openwave Mobile Browser Simulator available at developer. openwave.com.) N o t e Adobe Creative Suite 3 features many tools for designing and optimizing appli- cations for mobile devices. Learn more at adobe.com. N o t e Adobe Creative Suite 3 features many tools for designing and optimizing appli- cations for mobile devices. Learn more at adobe.com. Part I: Getting Started 34 Alternative Browsing Environments read them all at www.w3.org/TR/1999/WAI-WEBCONTENT-19990505. The United States government used the Priority 1 points of the WCAG as the basis for its Section 508 accessibility guidelines (see the sidebar, Government Accessibility Guidelines: Section 508). While accessibility and the techniques for achieving it are vast topics, I’ve summarized some of the guiding principles and provided pointers to useful resources here. Start with clean HTML. When your source document has been marked up with appropriate, meaningful HTML elements and the content appears in a logical order, your content will make sense in the widest variety of circumstances, whether it is read aloud or displayed on a tiny handheld screen. Provide alternatives. Always provide alternatives to non-text content such as alternative text or long descriptions for images, transcripts for audio, and captions for video content, to better serve users with various disabilities. Allow text to resize. If you use style sheets to specify font size, do so in rela- tive measurements such as percentages or ems (a unit of measurement for text equal to a capital “M” ) so that users can resize it with the browser’s “text zoom” feature (when available). Don’t put text in graphics. Although it may be tempting to control the typography of a headline by putting it in a graphic, doing so makes it less accessible by removing that content from the document. It also prevents users from resizing the text. Use accessibility features when creating HTML tables and forms. There are a number of attributes in HTML 4.01 and XHTML that improve acces- sibility by explicitly labeling columns or form fields. They’re only useful if you take the time to use them correctly. We’ll address these features in the tables and forms chapters, respectively. Be careful with colors and backgrounds. Be sure that there is plenty of con- trast between the foreground and background colors you specify. When using background images, be sure to also specify a similarly colored back- ground color so text is legible, should the image not load properly. For further reading The following resources are good starting points for further exploration on web accessibility. The Web Accessibility Initiative (WAI), www.w3.org/WAI WebAIM: Web Accessibility in Mind, www.webaim.org Dive Into Accessibility: 30 days to a more accessible web site, diveintoac- cessibility.org • • • User Preferences Chapter 3, The Nature of Web Design 35 Building Accessible Websites, by Joe Clark (New Riders) provides a com- prehensive overview. Joe Clark’s web site (joeclark.org/access) features Joe’s latest thinking and discussions on accessibility issues. User Preferences At the heart of the original web concept lies the belief that the end user should have ultimate control over the presentation of information. For that reason, browsers are built with features that enable users to set the default appearance of the pages they view. Users’ settings will override yours, and there’s not much you can do about it. This ensures that users who need to alter the presentation to meet special needs, such as enlarging type to com- pensate for imparied vision (or even just to read while leaning back in their chairs), are able to do so. • If you create a site for a Federal agency, you are required by law to comply with the Section 508 Guidelines that ensure that electronic information and technology is available to people with disabilities. State and other publicly funded sites may also be required to comply. The following guidelines, excerpted from the Section 508 Standards at www.section508.gov, provide a good checklist for basic accessibility for all web sites. A text equivalent for every non-text element shall be provided (e.g., via “alt”, “longdesc”, or in element content). Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation. Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup. Documents shall be organized so they are readable without requiring an associated style sheet. Redundant text links shall be provided for each active region of a server-side image map. Client-side image maps shall be provided instead of server- side image maps except where the regions cannot be defined with an available geometric shape. Row and column headers shall be identified for data tables. Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers. 1. 2. 3. 4. 5. 6. 7. 8. Frames shall be titled with text that facilitates frame identification and navigation. Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz. A text-only page, with equivalent information or functionality, shall be provided to make a web site comply with the provisions of this part, when compliance cannot be accomplished in any other way. The content of the text-only page shall be updated whenever the primary page changes. When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology. When a web page requires that an applet, plug-in or other application be present on the client system to interpret page content, the page must provide a link to a plug-in or applet that complies with §1194.21(a) through (l). When electronic forms are designed to be completed online, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues. A method shall be provided that permits users to skip repetitive navigation links. When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required. 9. 10. 11. 12. 13. 14. 15. 16. Government Accessibility Requirements: Section 508 . nature of the Web is particularly challenging if you have experience designing for print, where what you design stays put. As a print designer who made the transition to web design, I found. used to access the Web. In other words, you must design for accessibility. Accessibility is a major topic of discussion in the web design world, and a priority for all web designers. While intended. exploration on web accessibility. The Web Accessibility Initiative (WAI), www.w3.org/WAI WebAIM: Web Accessibility in Mind, www.webaim.org Dive Into Accessibility: 30 days to a more accessible web site,