202 HOW: HTML, the Building Blocks of Life Itself: WYSIWYG, My Aunt Moira’s Left Foot
WYSIWYG, MY AUNT MOIRA’S LEFT FOOT
We’ve all seen the ads: “Create web pages without learning a single HTML tag!” We’ve also seen ads that tell us how to lose weight while eating candy bars all day long. Strangely enough, we know no one who’s lost weight that way.
Today’s “What You See Is What You Get”( WYSIWYG) programs are far more powerful than the early, lame-o programs that gave WYSIWYG a bad name. But most professional web designers continue to use text-based web editors. Why? In a word, control. In four words, to avoid bad markup.
Code of Dishonor
Though we hope to see this change soon, nearly all WYSIWYG editors tend to write bloated (and often invalid) HTML markup. To make sure that every browser—even one that’s five years old—will be able to display your page as the program thinks you want it to be seen, these programs will grind out all kinds of unnecessary workaround markup, adding unsightly flab to every web page.
Other programs, notably one famous one we won’t mention for fear of lawsuits, tend to generate markup that works only in one browser. Coincidentally, this browser is made by the company that also makes the WYSIWYG program. Is this just bad design or an insidious marketing ploy? Ask their attorneys.
Beyond the twin plagues of page-swelling bloat and browser-specific “HTML,” there is the problem of artificial limitations imposed upon you by the designers of any WYSIWYG program you may use. Unless you work the code yourself, you cannot expand its capabilities or explore new creative terrain.
Citizen Kane was not shot with an autofocus lens. Great web pages are not built by using defaults. Use the markup, or you’ll be forced to depend on the kindness of strangers (otherwise known as software companies), to determine what you can and cannot do with your site.
Taking Your Talent to the Web |
203 |
With an autofocus camera, the man in the striped hat will be in perfect focus; too bad if you wanted to focus on the bird in the bush. Likewise, even with an advanced WYSIWYG editor, your options as a designer will always be limited. Comparing WYSIWYG editors to autofocus cameras is probably unfair—to the cameras.
Yes, these WYSIWYG programs are getting much better. Yes, a substantial number of pros do use them, particularly to rough out web pages quickly. But these pros always end up revising the end product by hand.
WYS Is Not Necessarily WYG
With a WYSIWYG tool, if you slap an image down 30 pixels to the right of another image, it stays 30 pixels away, even if you want it to move as the user’s window widens. If you drop an image onto the exact center of the WYSIWYG editor page, you might think the image is “centered,” but it’s not—it is stuck in an exact location, which may bear no relation whatsoever to the relative center of your users’ respective browser windows. (This is also the problem with using more advanced WYSIWYG editors to generate DHTML pages or CSS-based layouts. But we’ll get to those issues in time.)
WYSIWYG editors give you a false sense of control and a false sense of the Web. As explained in Chapter 2, the Web is not fixed like a printed page. It is fluid and variable and should be designed for accordingly. The tightlyrendered page that looks great in your WYSIWYG editor may look terrible on Aunt Moira’s monitor because your default fonts are larger than hers, or she doesn’t have the same fonts installed that you do, or just because she’s a silly thing who is going to leave her money to her cats, not you.
Suppose we intend to create a three-column layout with an image in the center column. Using HTML, this is no problem—we write a three-column table, set its borders to 0, and in a few moments, we are done. If we’ve used relative widths when constructing our table (<width=”33%”> for example, instead of <width=”200”>) the design will reflow to accommodate any user’s monitor, as discussed back in Chapter 2.
We can do the same thing with CSS, and before this book reaches its second edition, that’s what we’ll all be doing. With CSS such layouts are faster and easier to achieve, and the resulting web pages render more quickly.
204 HOW: HTML, the Building Blocks of Life Itself: Browser Incompatibilities
Now let’s build the same layout in a WYSIWYG editor. We drag three columns over a grid and place our image in the middle column. Unfortunately, we were two pixels off when we dropped our image, because the program lacks a “snap-to-grid” feature (or we forgot to turn the feature on). What does the program do? It calculates an 18-column cubist mess of code, using <ROWSPANS> and <COLSPANS> to make sure that our mistake gets perfectly rendered.
The program doesn’t know that our inexact placement of the image was an accident. The program cannot think; it can only execute, using tortured workarounds to honor our errors as hidden intentions. The result is a slow- to-download, tortuously coded fiasco—one which, after all that absurd markup and lengthy downloading, looks like garbage because the layout is subtly “off.”
And of course, it will never reflow to fit each user’s monitor just so.
Knowing HTML doesn’t make you a web designer any more than knowing your native language makes you a writer. But choosing not to know is senseless. Don’t trust the ads. Learn the markup. If you wish to use the better WYSIWYG programs to rough out your layouts, go ahead, but be ready to get in there later and refine your code.
BROWSER INCOMPATIBILITIES: CAN’T WE
ALL JUST GET ALONG?
Not only is there no WSY in WYSIWYG web editors, there’s no guarantee that any two browsers will display your page the same way or even that your page will work in every browser. Even if you write perfectly valid and standards-compliant code, old browsers are not standards-compliant, and the dream of “write once, publish everywhere” has not yet been attained.
Moreover, even on that great day when all browsers fully support W3C standards, extensive platform and hardware differences (as described extensively in Chapter 2) mean that the Web will remain evanescent and unfixed: a little different with each browser, in each monitor, and on each operating system. That kind of incompatibility is perfectly okay—there’s nothing we can do about it anyway. Incompatibilities that result in page failures are not okay.
Taking Your Talent to the Web |
205 |
One thing you can do is author in accordance with commonly supported web standards instead of to “nifty new features” that work only in one browser. By definition, you will be including more people if you avoid proprietary, browser-specific markup. Given that support for these standards varies widely and browsers may legitimately differ in the way they interpret some standards, you and your company’s Quality Assurance (QA) team will spend much time testing designs on a variety of browsers and platforms. (See Chapter 7, “Riding the Project Life Cycle,” if you skipped it earlier.)
Another thing you can do is visit The Web Standards Project (www. webstandards.org), read our Mission Statement (www.webstandards.org/ mission.html), and use the Project’s Resources section to learn more about standards (as well as incompatibilities). (In Chapter 10 we’ll talk about CSS incompatibilities and how to work around them.)
PUBLISH THAT SUCKER!
After you have created a website, how do you publish it? You publish it by sending your files and directories to the web server. This is done by means of an FTP program, so called because it uses the File Transfer Protocol (FTP) to do its work. Fetch is one common FTP program for the Mac; Interarchy (the FTP program formerly known as Anarchie) is another; and Panic Software’s Transmit (www.panic.com/transmit/) is a third—and the most Maclike. We still use Fetch, which has not been updated since the Pleistocene era, because the crusty old tool makes us feel that we are in UNIX, and that makes us feel all hardcore and stuff. WinFTP and CuteFTP are common Windows FTP programs.
To use an FTP program, you open it, type in the FTP address, user name, and password, and upload your files by dragging them from the open window on your desktop to the open FTP window. You can drag and drop hundreds or even thousands of files at once.
Note that unlike the Mac OS, an FTP server will not warn you if you are about to overwrite your files. Nor is there a comforting “Are you sure?” dialog box, such as in Windows. (Well, maybe the “Are you sure?” box is not
206 HOW: HTML, the Building Blocks of Life Itself: Publish That Sucker!
comforting, exactly, but it does help prevent mistakes. FTP does not.) Existing files, if present, will simply be deleted and replaced by the new file. Many a life, or at least, a weekend, has been ruined when a web designer dragged one file on top of another. So use care when naming your files. Many web designers rename old files before they update them (personnel.html becomes, for instance, personnelbak.html, or ~personnel.html).
Equally important is that depending on the rules of the FTP server, text files might have to be uploaded as text, or they will not work. Image files, along with Flash movies, sound files, and so on, might have to be uploaded as binaries, or they will not work. Doddering old Fetch has a checkbox for “automatic” detection of text or binary. That checkbox is your friend. Check it and you will not be faced with the mysteries of the nonworking site.
Finally, as we’ve emphasized all along, it’s important to make sure that your files end in appropriate extensions (.jpg for JPEG images, .html for HTML documents, and so on) and that you have paid attention to their capital- ization—or lack thereof.
Offline, you can get away with mismatched cases. For example, <IMG SRC=”mydog.gif”> might work just as well as <IMG SRC=”MYDOG.GIF”> or <IMG SRC=”mYdOg.gIf”> when you’re testing the web page offline on your hard drive. But almost all web servers are case-sensitive. (Windows IIS does not seem to care one way or the other.) On most servers, if the file is named mydog.gif and your HTML refers to <MyDog.gif>, the image will not show up on the Web.
Many web designers avoid this problem by using only lowercase for their filenames: mydog.gif—never MyDog.gif or MYDOG.GIF.
Sticking to lowercase and coding all references in lowercase may save hours of tedious labor. You’ll also protect your clients and your site’s potential visitors. Because most folks who’ve spent time on the Web have noticed (consciously or unconsciously) that nearly all URLs are lowercase, when they hear your client’s ad they’ll type http://www.widgets.com. They will not type HTTP://WWW.WIDGETS.COM. Stick to lowercase so your client’s visitors can actually view the site.