Taking Your Talent to the Web- P21 pps

the seven CSS keywords directly to the seven Netscape font sizes. In many ways, it was a logical and even brilliant thing to do. (The IE/Windows developers were also the first group to attempt to support absolute font size keywords. We should credit them for that before carping about the results.) The problem, of course, is that, logically, the sizes do not map to the keywords. In old-style browsers, <FONT SIZE=3> is the default or normal size that the user has specified in her preferences. In Netscape’s extended HTML markup, <FONT SIZE=3> is assumed unless you specify another size. Logi- cally, a default size should map to the “medium” CSS keyword. Unfortu- nately, in the IE/Windows scheme, <FONT SIZE=3> maps to “small” instead of “medium” because small is the third size up from the bottom of the list. Who goofed—the W3C or the IE/Windows team? It doesn’t really matter. What matters is that the keywords don’t map to expected sizes, and an incompatibility exists not only between different manufacturers’ browsers but between the Mac and Windows versions of the same browser. If you think of the seven sizes the way the IE/Windows team did, your sizes will be off on Mac users’ desktops. (You also will go nuts. It’s like trying to drive a car where Park means Neutral.) If you think of them the way the keywords actually read (small, medium, large) your display will be off in Windows. You can trick the Mac browser into emulating Windows behavior by specifying a <DOCTYPE> of HTML 4 Transitional and leaving off the W3C URL. (For details, see http://www.alistapart.com/stories/ie5mac. But this is forcing the browser to emulate nonstandard behavior, and that's not good. Besides, it won't work in Netscape 4, Opera, or Konqueror. So what can you do? Sadly, until your entire audeince uses browsers that render absolute keywords, all you can do is ignore the W3C recommenda- tions and use pixels in your style sheet. Or do not use sizes at all. Relative keywords Relative keywords are limited to two: smaller and larger. These in turn refer to the size of the parent element. For example, consider the following example, in which the <BODY> is 12px, and <BOLD> is “larger.” 281 Taking Your Talent to the Web 14 0732 CH10 4/24/01 1:04 PM Page 281 <HTML> <STYLE TYPE=”text/css”> <! BODY {font: 12px verdana, arial, geneva;} B {font-weight: bold; font-size: larger;} > </STYLE> Bold type would theoretically be 14px tall in this example because 14px is one “notch” up from 12px. Like absolute size keywords, relative keywords are ignored or bungled in some popular browsers (Explorer 3 ignores them, as does Navigator 4 for the Mac). And even if they worked correctly, they would be insufficient for the needs of most web designers and their clients. Normal, larger, and smaller is not exactly a robust vocabulary for the needs of professional designers. So what can you do? You can use pixels in your style sheet; that’s what you can do. Length units Length units sound smutty (those W3C folks should get out more…or maybe it’s just us) and include the following: ■ em—Is a unit of distance equal to the point size of a font. In 14pt. type, an em is 14pts. wide—named for the size of the capital “M.” But you knew that.) ■ ex—Refers to the height of lowercase letters. When used with the font-size property, em and ex units refer to the font size of the parent element. <HTML> <STYLE TYPE=”text/css”> <! BODY {font: 12px verdana, arial, geneva, sans-serif;} STRONG {font-weight: bold; font-size: 2em;} > </STYLE> 282 HOW: Style Sheets for Designers: Trouble in Paradise 14 0732 CH10 4/24/01 1:04 PM Page 282 In this example, <STRONG> would be 24px tall, or 2em (two times the font size of the parent element, which is the <BODY> tag). In theory, a web designer could create a layout using em or ex units, where all elements were sized relative to each other. This would avoid the accessibility problems associated with pixels. Unfortunately, the browsers make this impossible for the time being. Netscape 4 ignores em and ex units. IE3 treats em units as pixels. Thus, 2em is mistranslated as 2 pixels tall. It takes a village to raise a child, and it takes at least 9 pixels to render a font. Length units are therefore not recommended. What is recommended? Pixels or nothing. Percentage units Percentage units, like length units and relative keywords, refer to the size of the parent element. <HTML> <STYLE TYPE=”text/css”> <! BODY {font: 12px verdana, arial, geneva, sans-serif;} STRONG {font-weight: bold; font-size: 200%;} > </STYLE> In this example, <STRONG> would be 24px tall, or 200% of the font size of the parent element, which is the <BODY> tag. In theory (notice how we keep saying “in theory"?), a web designer could create a layout using percentages and avoid the accessibility problems associated with pixels. Nothing is sadder than the murder of a beautiful theory by a gang of ugly facts. Netscape 4 for Mac renders percentage units when they are used for line-height (leading) but ignores them entirely when they are used to specify type sizes. And some versions of Netscape 4 for Windows treat percentages as pixels. (Thus, 200% is dementedly translated as 200 pixels. Mmm, nice layout.) 283 Taking Your Talent to the Web 14 0732 CH10 4/24/01 1:04 PM Page 283 Lest we forget, good old IE3 drops the ball by sizing percentages relative to the user’s default font size rather than to the parent element. In Eng- lish: If the web user has set her browser’s default to 10px, IE3 will display <STRONG> at 20px and not the 24px you intended. If her browser defaults to 16px, <STRONG> will be 32px. Too bad for you. Too bad for your visitor. In spite of their accessibility benefits, percentages still fail in too many browsers. What works? Pixels—pixels or nothing. In case we’ve failed to communicate, we will summarize our findings as follows: Looking Forward Web designers will continue to be limited to using pixels in their style sheets—despite the accessibility hazards associated with that practice— until fully standards-compliant browsers exist and are widely used. The approach might have its drawbacks, but failure to work correctly is not one of them. As web designers, our job is to control the visitor’s visual experience to communicate. For the time being, the approach outlined here will allow us to do exactly that. And soon enough, Lord (and browser compa- nies) willing, the full power of CSS will be ours. Can you take CSS further today? Quite possibly. It depends on the makeup of your audience and your salesmanship with clients. As explained in Chap- ter 13, A List Apart converted to an all-CSS layout in February 2001, and many sites have since followed suit. For details and encouragement, see http://www.alistapart.com/stories/99. 284 HOW: Style Sheets for Designers: Trouble in Paradise 14 0732 CH10 4/24/01 1:04 PM Page 284 chapter 11 The Joy of JavaScript WE’VE SAID ALL ALONG that the Web is not print. If you’ve harbored lingering doubts on that score, this chapter should clear them up pronto. If this chapter does not clear them up, try club soda and a semiabrasive cloth. A primary reason the Web is not print is that websites don’t just sit there; they do things—responding to clicks of the mouse, hovering motions, and other user activities. JavaScript is behind much of that interactivity. In JavaScript parlance, user actions such as mouse clicks are called events, and you handle them via event handlers (“onClick,” for example). Similarly, in JavaScript, the components of a web page, such as GIF images and form buttons, are considered objects. Web pages are known as documents, and the whole shebang is held together by a Document Object Model (DOM). See, it’s not that hard, and you are learning already. In this chapter you’ll find out what JavaScript is, where it came from, how it brings websites to life, where to learn all about it, and how to begin using it even before you learn all about it. You’ll also learn how to communicate desired JavaScript functions to the developers on your team, who will handle the heavy scripting when it is needed. If you freelance or work in a graphic design shop instead of a web agency, you’ll learn how to communicate with freelance programmers. But before you can begin doing any of that, a few basics are in order. 15 0732 CH11 4/24/01 11:23 AM Page 285 WHAT IS THIS THING CALLED JAVASCRIPT? JavaScript is a programming language designed specifically to work in web browsers. Its purpose is to bring interactivity to sites. Though JavaScript is powerful and complex, it is relatively easy to learn—at least it is easier to learn than many other programming languages. Even before JavaScript, sites could be somewhat interactive. After all, clicking a hyperlink loads a new page. The nonlinear nature of hypertext allows the reader to decide where to go next—to structure her own voyage through the site (and, indeed, through the Web). That is an interactive process and a rather profound one. But it is not a ter- ribly sophisticated form of interactivity. JavaScript puts the top hat and tails on web interactivity. The Web Before JavaScript Before JavaScript, programming languages such as Perl were used to facil- itate interactive processes, for example typing text into a form and clicking a button, thereby sending requested information to the site’s owners. Perl is still often used for this purpose on a great many sites. But Perl is a server-side scripting language. That is, when a visitor clicks the Send button, the web server itself must process the script. If the server goes down or malfunctions, nothing will happen. Likewise, a web page not con- nected to a web server—say, a web page on your hard drive—would not be able to process such a script except in special circumstances (permanent Net connection, full URL specified in the <FORM ACTION>, burning of incense, wearing of magic ring). While the script is being processed, the web server is momentarily tied up— just as your Mac or PC gets tied up when you apply motion blur to an image in Photoshop. Imagine constantly applying motion blur while receiving and sending email, and you begin to see what web servers were up against. (This is, of course a crude picture, and if you like it, we have other crude pictures available at a nominal price.) 286 HOW: The Joy of JavaScript: What Is This Thing Called JavaScript? 15 0732 CH11 4/24/01 11:23 AM Page 286 As the Web’s population grew, more and more users were clicking more and more Send buttons. More and more web servers were thus spending more and more time processing scripts in between serving web pages. Mean- while, the user’s browser sat there, doing nothing. A tool was needed to transfer the process from the server to the client (the user’s computer). Enter JavaScript. JavaScript, Yesterday and Today In 1995, the company formerly known as Netscape Communications Cor- poration introduced a client-side programming language designed to transfer the burden of interactive processing from the web server to the end-user’s browser. Unlike other programming languages (such as Java or C), this new language was built into the browser. It even understood HTML. Netscape called its new client-side scripting language LiveScript, but soon changed the name to JavaScript to capitalize on the growing excitement about Sun’s Java language. To this day, as a result of their similar names, many beginning web designers (and users) confuse Java with JavaScript. The relationship between the two is mainly one of marketing. Netscape quickly promised to release JavaScript as a web standard so that other browsers could use it too. But for competitive reasons, the company initially held back on its pledge. Old browsers like Mosaic could not use JavaScript at all. Neither could Microsoft’s newly unveiled Internet Explorer. To offset Netscape’s advantage, Microsoft’s browser engineers developed a JavaScript-like language called JScript. Web design quickly became a cir- cle of Hell, as serious developers were forced to work with these similar but incompatible technologies. Freelancers and small firms, lacking deep resources, often chose to support only one technology. That one was nearly always JavaScript, especially in the beginning when Internet Explorer enjoyed only a tiny share of the market. Thus JavaScript functioned as a sort of standard before it really was one. 287 Taking Your Talent to the Web 15 0732 CH11 4/24/01 11:23 AM Page 287 Around the Millennium, JavaScript finally became an official web standard, available to all. As reported in Chapter 2, “Designing for the Medium,” the European Computer Manufacturers Association (ECMA) supervised the standardization of JavaScript, renaming it in the process. The universal web scripting language is now officially known as ECMAScript or ECMA-262, though no one we know calls it anything but JavaScript. (Our Scandana- vian friends pronounce it “Ya-va-script,” which we find incredibly endear- ing. That has nothing to do with any of this, but it does lend this chapter a certain international flair.) The point is that JavaScript/ECMAScript is a standard that works in all cur- rent browsers, though there are still some subtle incompatibilities being worked out between the latest versions of Netscape, Internet Explorer, Opera, and other browsers. Meanwhile, the DOM has been standardized by W3C. Prior to that, JavaScript had its own ever-changing DOM in Netscape, and Microsoft had its own DOM as well. As all browsers finalize complete support for these standards, web designers and developers are being empowered to create sophisticated interactivity that works for everyone. Conversely, as browsers lag in their DOM and ECMAScript support, web designers and developers are stuck programming alternate versions of every site function, often going so far as to develop alternate versions of the sites themselves. Now that we’ve concluded our mini-history lesson and you’ve finished your nap, let’s move on to the good stuff. JAVASCRIPT,UNHH! W HAT IS IT GOOD FOR? Absolutely lots of things. Through this web-friendly programming language, designers and developers can: ■ Replace cryptic status bar URLs (“http://www.doglovers.com/ poodles.html”) with text messages (“Learn about poodles”), a somewhat controversial practice, for reasons we’ll discuss in a moment. ■ Create the ever-popular image rollover effect discussed in Chapter 9, “Visual Tools.” 288 HOW: The Joy of JavaScript: JavaScript, Unhh! What Is It Good For? 15 0732 CH11 4/24/01 11:23 AM Page 288 ■ Compensate for browser incompatibilities. ■ Open new, precisely sized “pop-up” windows, with or without various bits of browser chrome. ■ Test for the presence or absence of Flash, QuickTime, or other plug- ins (more about plug-ins in Chapter 12, “Beyond Text/Pictures”). ■ Rotate content and images depending on the time of day, the num- ber of times the user has viewed a certain page, or simply at random. ■ Enable the client to inject 50 links on a page without cluttering that page at all. ■ Provide alternative means of navigating the site. ■ “Remember” that a user has visited the site before, sparing her the pain of reentering personal data or passwords. This is accomplished by means of cookies (Netscape terminology for little bits of text that reside on the end-user’s hard drive and can be recognized by JavaScript on subsequent visits to the site). ■ Cause images or text boxes to scroll horizontally or vertically, another controversial and often annoying practice. ■ Verify the credibility of email addresses entered on “customer feed- back” forms. JavaScript won’t tell you if a person is using her email address or someone else’s, but it will tell you if the address is well formed or not. (If malformed, it is probably a nonworking address.) ■ Control complex frames—of less importance than it used to be, as frames are gradually being phased out. Similarly, JavaScript can pro- tect sites from a third party’s poorly crafted frames. ■ Create nested navigational menus that reveal secondary and tertiary levels in response to cursor movements—a wonderful idea because it enables visitors to navigate directly to the information they seek, but problematic because not all browsers fully support a standard means of doing this. ■ …and much more. Add the W3C DOM to what JavaScript does already and you can change that phrase to “much, much, much more.” 289 Taking Your Talent to the Web 15 0732 CH11 4/24/01 11:23 AM Page 289 We know what you’re saying. “Sounds great, but I’m, like, an artist. Do I really have to learn this stuff?” SOUNDS GREAT, BUT I’MANARTIST. DO I R EALLY HAVE TO LEARN THIS STUFF? The politically correct answer is, yes you do, because adding interactivity to your clients’ sites is part of what makes you a web designer. The gentle answer is, learning JavaScript is an iterative process: You can begin by cutting and pasting and gradually come to understand what you’re working with. The Richard Nixon Memorial answer is, not at first, and maybe never. Not at first and maybe never is an answer because many working web designers get by for years doing nothing more than cutting and pasting other people’s scripts. By the way, we’re not talking about stealing code. Many developers freely offer their scripts in return for an acknowledge- ment in the source code, and some don’t even ask for that (http:// javascripts.earthweb.com/). Likewise, many other web designers get along by using WYSIWYG editors such as Macromedia Dreamweaver and Adobe Golive and image editors such as Macromedia Fireworks—programs that can create many standard JavaScript functions for you. Some respected web designers have never programmed a line of JavaScript code; they let Dreamweaver do it. But most web designers do learn at least the basics of JavaScript because, sooner or later, they run into problems they cannot solve without it. A problem like this can occur: A certain page does not display properly in Netscape 4. The solution would be to create an alternate page that does work in Netscape 4 and use JavaScript to send Netscape 4 users to that alternate page. For nearly every design problem like this, there is a simple JavaScript solution. The other problem with cutting and pasting (or relying on a WYSIWYG edi- tor) is that browsers change, web standards evolve, and cut-and-paste scripts as well as WYSIWYG editors tend to lag behind. 290 HOW: The Joy of JavaScript: Sounds Great, but I’m an Artist 15 0732 CH11 4/24/01 11:23 AM Page 290 [...]... “HTML, The Building Blocks of Life Itself.” There is no need to waste bandwidth by including http:// or the company’s domain name in the link; both the http:// and the domain name are understood There is also no need to waste bandwidth on “index.html” because the systems administrator will have configured the server to display index.html when no other document is specified (Some systems administrators... better would it be if the visitor saw a message like this? FASHION MAVEN fashions for men 15 0732 CH11 4/24/01 11:23 AM Page 295 Taking Your Talent to the Web Many visitors might find this message far more useful than a bare-naked URL And your client would certainly dig it Fortunately, it is easy to accommodate these visitors and your client with JavaScript Text rollovers are one of the easiest effects... from the napkins to the silverware He expects the same level of branding on his site Solution: The JavaScript text rollover lets you brand even HTML links (see Figure 11.1) Figure 11.1 The status bar text rollover in action at the personal site of Derek Powazek Placing the mouse over DESIGN FOR COMMUNITY in the menu bar causes the phrase [DESIGN FOR COMMUNITY] to appear in the status bar at the bottom... designer, you really should be able to use JavaScript to do simple things such as replacing meaningless URLs with text messages as a means of extending the site’s branding (And ducking when some visitors complain about it.) 15 0732 CH11 4/24/01 11:23 AM Page 293 Taking Your Talent to the Web You should be able to create rollovers (image swaps) that help your visitors experience the site as a responsive, interactive... Page 291 Taking Your Talent to the Web Hopefully, Microsoft, Netscape, and Opera will soon patch the holes in their ECMAScript and DOM support, and Macromedia and Adobe will vastly improve their support for these standards in Dreamweaver and Golive, respectively If both things happen, you might be able to spend the rest of your life banging out advanced JavaScript functions with no clue as to what you... hotwired.lycos.com/webmonkey/javascript/tutorials/tutorial1.html) Give yourself at least two days to go through all the exercises in this five-part tutorial The JavaScript School at www.w3schools.com/js/ is another great place to learn Classic and recent JavaScript/DOM articles may be found at http://www.javascript.about.com/ We highly recommend that you buy these books and study these free online tutorials We also recommend... how to open new browser windows (when doing so serves a purpose), use browser detection to solve compatibility problems, and enhance your site’s navigation through JavaScript’s ability to manipulate simple HTML elements The techniques involved are as simple to learn as they are to demonstrate Don’t mistake simplicity for stupidity: Some of the simple things we’re about to show you are among the. .. instead, but the same rules apply If default.htm is the default document on your server, you can link to it without typing it But we digress.) A visitor dragging her mouse over such a link will see the page’s URL and nothing more: http://www.fashionmaven.com/fashions/men/index.html Let’s give the visitor something more informative than the page’s URL The Event Handler Horizon Built into JavaScript... intend to work primarily as a graphic designer and merely wish to create simple sites for your existing clients, you can probably get by with cutting and pasting or relying on Dreamweaver or Golive—at least for the time being But if you intend to plunge into full-time web design or if you simply want to master the craft, you will want to learn JavaScript So let us tell you how you can do that, and then... sites or on sites whose lack of in-depth content is made pitifully obvious when these complex menus end up pointing to single-paragraph pages While other jazz musicians blew fast and frantic, Miles Davis played very few notes The way he played them, when he played them, and the many times he did not play at all, all combined to create a timeless creative legacy This is our highfalutin’ way of reminding . 283 Taking Your Talent to the Web 14 0732 CH10 4/24/01 1:04 PM Page 283 Lest we forget, good old IE3 drops the ball by sizing percentages relative to the user’s default font size rather than to the. Mean- while, the user’s browser sat there, doing nothing. A tool was needed to transfer the process from the server to the client (the user’s computer). Enter JavaScript. JavaScript, Yesterday and Today In. failure to work correctly is not one of them. As web designers, our job is to control the visitor’s visual experience to communicate. For the time being, the approach outlined here will allow us to