The other day I ran a highly constrained Google search for one of my ancient pseudonyms (yes, thank you, moving to the country has left me with a glut of free time) and discovered my first Usenet post, circa July, 1994. And let me tell you, nothing, NOTHING makes you feel older than reading the ranting of your ten-years-younger self.
Chances are your first Usenet post either predates mine or you have no idea what I’m talking about (if you’re the latter, all you “need” to know is that Usenet was Deja.com before Google bought it). While Google still indexes the really old posts, it doesn’t let you sequentially scroll through stuff that predates early 2000, so unless you know exactly what to search for — a person’s ancient cyberpunny handle, say — you’re probably not going to turn up anything. And thank god; I really don’t need that part of my past surviving in perpetuity (mark my words:<meta name=”robots” content=”noindex, nofollow”>).
If unearthing ancient Usenet posts makes you feel old, try re-entering the world of Web design after a five-year hiatus.
“I was up really late working on a … website,” I told my brother, pausing sheepishly in the silence on the other end of the phone. “I think I’m, uh, going back into Web design.”
“Wow. How retro,” was his only response. And I don’t think he meant that in the “retro cool” sense. No, not at all.
Not only was I was old and uncool, but I my tech skills were dated. My CSS knowledge was abysmal. I had no idea there was almost complete browser support for CSS Level 1. In fact, I didn’t even know about CSS Level 2. You can control the printer output of your pages? And speed at which pages are read out loud? Who am I, Rip Van Winkle?
And, oh!, what about the poor meta keyword tag?
In case you haven’t been keeping up, the meta keyword as we knew it is dead — or at the very least radically reinvented. The meta tag used to be a fun place to stash random words to amuse my source code readers. Maybe I wasn’t pushing my $exxx!!!! site, but it is true that I, apparently along with millions of others, violated the practical intent of that tag.
Since indexing engines no longer trust us to use our meta tags to tell the truth, instead they read our pages, count the frequency of words, and knock points off our ranking for obvious redundancies, invisible text (e.g., white text on a white background), and other cheesy methods of search engine chicanery. They read our page titles and the meta description content looking for keyword clues, and then they read the first paragraph. If your first paragraph is nothing but an empty table cell, or GIF text lacking an ALT attribute, you’ve undermined the promotion power of your description content.
And then those indexing engines follow your links. They don’t simply scan the rest of your site, they also follow your offsite links, evaluate the content and keywords of those sites, and adjust their sense of your site’s keywords accordingly. In other words, if your website’s about horses, link to other sites about horses not just the local diner down the street from your stable.
You also need to be careful with the text of your site description (<meta name="description" content="The Heidi FAQ" />). Remember that the text of that may not be read in its entirety. Many search crawlers don’t make it past the first 50 characters — this includes punctuation and spaces between words. If you want your description to work, avoid rambling poetics. Don’t say, “The rustic, pastoral wonderland of my fabulous life on Sunny Acre Horse Farm.” Try something like, “Horse riding, training, jumping, dressage, board. Sunny Acres Millbrook New York”. That example, by the way, is exactly 80 characters long, the maximum length any spider will cache.
The other text a search engine spider parses for keyword clues are the contents of your headers. Not the cute banner logo spanning the top of your page, actual, bona fide, header tags:H1, H2, H3… What? Not using header tags because they look ugly? That’s why god invented CSS.
CSS Delivers Us from Evil
THIS SECTION NEEDS UPDATING. Please log in and contribute by editing it.
Surely you’ve read Mulder’s Stylesheets Tutorial by now? If you haven’t, best get to it, because the time for stylesheets is now.
In olden times, we coded pages for backwards compatibility. We did so partly because it was secretly cool to remain Lynx compatible, and partly because the newest codes were proprietary implementations not backed by any standards consortium. By implementing the newest bells and whistles, we were designing for a relatively small group of early adapters and alienating all the users who lagged because their companies refused to let them install new, non-approved software, or because downloading increasingly fattened applications over dial-up connections was too painful, or just because old habits die hard. But now that the bulk of the user base runs CSS1-compliant browsers (98 percent of Web surfers have managed to upgrade to at least a 5x browser), those of us who refuse to design using CSS are almost as lazy and outmoded as those users who haven’t upgraded their 4x browsers.
Are you one of the ever-dwindling number of CSS resisters? Just what is it you’re worried about, shunning a small cadre of outmoded users? If you’re truly concerned about platform diversity, then you should absolutely be using CSS to meet the needs of all your visitors — old, new, and the cutting-edge small-screen, WAP-enabled users. The time is nigh for you to whip up some stylesheets geared to the different audiences and let browser sniffers decide who gets what.
Please note that we’re talking CSS1 here. CSS2 still has yet to be widely implemented, but CSS1 was ratified way back in 1998 and runs on any 4.x+ browser. In case a 4x browser doesn’t seem that ancient to you, let me explain. Internet Explorer 4.x for Windows is over four releases old (they’re up to 6.0 now, having passed through 5.0 and 5.5). Netscape is on version 7, despite the fact that 4.7 still resides on many System 9 Macs, albeit right alongside IE 5.0, one of the best CSS-compliant browser at the time. Anyone with Apple’s OSX would have to work to be non-CSS-compliant, what with the spectacular native Safari and IE 5.2. Opera, which was almost perfectly compliant from the beginning, is also up to a version 7, again three major releases beyond its nascent 3.5. Linux folks, of course, are almost always standards compatible.
So the information that follows pertains to CSS1 as supported in the major browsers of 5.x-and-above caliber. (If you are still truly concerned about those older models, Westciv has a great CSS compatibility chart that deliniates support for all the big-name players, including their 4.x releases.)
Ready? OK then let’s move on to all the down-and-dirty, tag-by-tag issues and concerns.
Playing Tag – Rules and Regulations
For text formatting with complete peace of mind, feel free to use any of the following:color, font-family, font-size, font-style, line-height, text-align, text-decoration, and letter-spacing. Font-weight is slightly iffy for anything other than straight bold (the “lighter,” “bolder,” and numeric properties still have some kinks). Text-indent has some mysterious issues with IE 5.0 Windows, but is otherwise dandy. Word spacing unfortunately has problems in IE Windows up to version 5.5. Vertical-align has partial support in almost every browser, by which I mean that baseline usually works but super, top and text-top tend to be identical and “middle” suffers from a variety of interpretations. The first-line and first-letter pseudo-class are supposed to work but I’ve found it’s best to use them only in conjunction with an explicit line-height lest they muss things up. Display and white-space should not be counted on, nor should most of the list-style properties.
All the CSS1 background properties work, as do borders properties (though the border styles can render awkwardly with large pixel widths and the shading schemes employed by the four beveled formats will often highlight in greyscale, ignoring any color specifications). IE 5.0 for Windows is the only post 4.x browser that might give you problems with differing side parameters (for instance, when you set properties for the top and sides but not the bottom).
Width and height are good to go, but be wary of the CSS box model:If you set a height that’s too small to contain your text, it will bleed beyond the box borders. Not only will that look super strange to begin with, but technically a browser should render subsequent text on top of the overflow, making everything unreadable. Float and clear work perfectly well although you need to pay close attention to the parent and child relationships surrounding them or you’ll end up with unexpected wrap results. In general, improper or sloppy coding that flouts cascade inheritance rules will result in some very odd effects across platforms; the browsers may be compliant with the standards, but they will differ in their treatment of code that isn’t.
When I was little, the only formatting tricks we had relied on structural HTML tags like H1 and UL and EM. You may think I’m just being nostalgic, but these tags are still the key to your future with CSS.
As I’m sure you know, the CSS class selectors are the means by which you can attach different formatting styles to a single HTML tag. Be warned:While you can design an entire site using only <P>, shunning HTML tags like headings and lists, you do so at the risk of shunning search engines, new Web-browsing devices, and older browsers. What, you really thought I didn’t care about those people?
Because search engines take note of text contained in heading tags, you should probably consider using a few. If you don’t like the giant bold all caps default H1 formatting — who does? — just use class selectors with H1 tags to get different effects. Use H2 and H3 or even all six, but keep in mind that they are intended to provide structural information about a site. For this reason, the heading tags are block-level elements and will cause line breaks — as opposed to inline elements like <B> or <SPAN> which allow you to format specific words within lines and paragraphs. In other words, you can’t just go around wrapping random body text keywords inside heading tags to fool a search crawler.
The other group of structurally minded HTML tags are list elements (UL and LI). These become quite powerful with CSS because LI are natural child elements of UL (and OL), meaning that they inherit formatting automatically from the parent. Instead of creating a huge list of class selectors, you can harness the power of the cascade with these tags. Unfortunately, even though you can set the bullet property to none and futz with line-heights, many browsers still automatically create hanging indents for LI even if you’ve set that attribute to zero or a negative. So if you have any latent control-freak tendencies, I suggest you limit your use of the list tags.
Now that we’re armed with the formatting power of CSS, there are inline HTML elements that perform text formatting tricks which merit a second look. Notably, em (for “emphasis”) and strong (for “strong”) are part of a class of tags historically used to force Lynx and other text-only browsers to render fonts in italic and bold, respectively. These tags, along with the heading tags, fell out of use over the last ten years because we all got hooked on the FONT tag. We couldn’t specify font faces, colors, or sizes for these old school tags until the widespread adoption of CSS.
You can still use I and B to format italic and bold text, and these will degrade perfectly well. But suppose you have words you’d like to highlight in other ways, such as turning text bright red, or outlining it in a little box? Instead of assigning these attributes to a P class, you can assign them just as easily to EM or STRONG, with the bonus being that older, not-fully-CSS-compliant browsers will at least render your text in some notable italic or bold fashion.
There is one important caveat:Because EM and STRONG are associated with traditional formats, failing to specifically redefine them in your style sheet will cause their inherent italic or bold styling to appear by default. In other words, if you set EM to 16pt red, but forget to set the font-style to “normal”, your EM text will show up large, red and italic.
One old HTML tag you need to stop using right away is FONT. It may work in older browsers, it may still work in some new browsers, but it’s being phased out in lieu of stylesheets. Standards aside, using the FONT tag bulks up your code, which may not matter over high speed or dial-up connections, but does matter to people using wireless devices with their pokey download speeds. It’s also annoying to edit each and every FONT tag when you want to make global style changes. And lastly, because you have to write out the face names over and over for each individual FONT tag, it tends to lead to minimalist font design. I don’t know about you, but I’m getting a little tired of the ubiquitous verdana, arial, times new roman, georgia, courier look. Just once I’d like to see someone bust out with something a little more creative, even if only in the occasional header. If you’ve stuck to the generic line up out of confusion about cross-platform installed fonts, may I suggest you burn an afternoon familiarizing yourself with the lesser known fonts available to Windows and Mac users?
Now for a look at some of the finer points on alignment using div, span, and the doomed center tag.
Div and Conquer
Bid a fond farewell to the center tag, everybody. Instead use the block-level div tag with alignment set to “center”. If you’re really concerned with backwards compatibility, you can use both simultaneously, but even Lynx respects the centered div tag, so I honestly can’t imagine this being too much of a worry.
The SPAN tag, basically the inline version of div, was introduced with HTML 4.0, way back in 1997. Because of its inline nature, a SPAN tag with no stylesheet definition won’t alter your text in any way, so it’s virtually invisible to non-CSS compliant browsers. If you set span to 16pt red and wrap it around the first word of every paragraph, users with CSS-compliant browsers will see a giant red word leading every paragraph while users with older browsers see just plain, boring text. So if you’re using span for highlighting purposes, you might consider using em or strong to ensure better degradation.
Float is the fancy new CSS way to align images and bits of text. It allows for more powerful wrapping and margin control than HTML’s img alignment attributes. Theoretically, you can use the SPAN tag in conjunction with the float property but this can have some very strange consequences in less-than-perfect browsers. Why would you want to do this? I can think of a number of good reasons, mostly having to do with immersing images inside paragraphs, but two column tables also come to mind. Say you have a nice price list and you just want the items to line up on the left with their costs aligned to the right. Technically, you should be able to wrap those numbers in a span tag with a float:right attribute and have the text float to the right of the top of the parent element (e.g., the paragraph or, in this case, the single line item). You should be eager to employ this approach instead of using a table because you won’t have to resize your table cells for tiny cell phone or PDA browsers. Unfortunately, most of the Windows browsers don’t seem to treat span as the inline element it is; they treat it like the block-level div tag and consequently float things items aligned with span the parent element, wreaking havoc with your good intentions.
And with that whirlwind tour of the basic Pro’s, Con’s, Do’s, and Don’t’s, I send you out into the WWW to put your new-found CSS skills to the test, perhaps in conjunction with XHTML? Either way, I suggest you hop to it, stat — after all, neither one of us is getting any younger.