At Tuesday’s co-working session, I talked about a few of the basics of HTML and CSS (as best as I could within two hours, that is). One of the focal points of the session was the importance of laying a strong foundation for a well-built Web page via semantic HTML that strictly separates content from presentation. We also walked through building a quick-and-dirty page with HTML and CSS while keeping focused on the importance of semantics and standards.
Why semantically sound HTML is important
While I see far fewer sites laid out with tables these days (thankfully!), there are still some issues to address. One example I often see is the use of tags like <blockquote> to indent text. While, yes, <blockquote>’s default style is indeed to indent text, <blockquote> tags should be reserved for text that is actually a long quote, not only because it’s the right thing to do with long quotes but also because each browser will set differing defaults for padding, margin, and indentation. While the end result is often acceptable, relying on HTML code like <blockquote> or <center>l; for formatting takes away significant flexibility, bloats Web pages, and can often lead to unpredictable behavior across browsers, which just creates more work for a developer (especially since we already have to deal with Internet Explorer’s quirks).
Coding to standards is especially important when working on a site collaboratively. For example, say we have one person using <blockquote> to indent text while another is using <blockquote> for legitimately setting off long quotations. Now, in the site’s redesign, the designer applies a stylesheet which adds a background image of a quotation mark to each <blockquote> element. We now have quite a potential layout snafu for all the pages in which <blockquote> was applied as an indentation method rather than setting off legitimate quotes. It becomes nonsensical to readers and requires a lot of extra cleanup work that could easily have been avoided if the standard were simply followed.
Better living through reset.css?
In recent months, I’ve experimented with Eric Meyer’s CSS reset, which is intended as a baseline to smooth out inconsistencies between each browser’s default display settings. I’ve adapted the reset with pretty consistent success. That being said, it may not be for you or fit your project. if you reset, be sure to tailor it for your own project to keep things efficient and un-bloated. Meyer’s reset can be overkill for most implementations and should be scaled accordingly. (If you have time, the comments on the Jens Meiert post questioning the wisdom of resetting offer a great discussion about the merits of resets.)
Use the right tools
During the session, I also stressed the importance of using the right tools for the job. There are so many wonderful (and free!) code editors out there with color-coding and autocompletion now that it’s absurd not to use one.
On the Mac, I use Panic’s Coda shareware ($100 to license) for my development projects. Its fully-integrated environment plays well to the Mac’s UNIX underpinnings and has become indispensable in my arsenal. Other editors I like and endorse include Notepad++, a fast and astoundingly flexible code editor for Windows (it was one of the hardest things for me to give up when I switched to the Mac last August) and Aptana Studio, an Eclipse-based IDE that offers some of the most intelligent code completion I’ve seen, complete with popup displays that show you browser compatibility at a glance. Too cool.
Like anything else, it’s important to check your work. Make sure your code is solid with the W3C’s HTML validator, and install a wide range of browsers to test. Windows users can avoid the need for multiple VMs to run different versions of Internet Explorer by using IETester, which combines different versions of the IE rendering engine into one window, allowing you to test your sites on versions of IE as old as 5.5. To run IE, Mac users will need to run VMs; basic VMs are easy with a free tool such as VirtualBox (though Windows licensing rules still apply).
Also, I strongly recommend looking into running Lynx, the most popular text-only browser. It provides a fascinating perspective on your coding by showing you the bare bones, text-only view of your page. This is what machines see, so it’s important to make sure the text-only version of your site is sensible, navigable, and free of unnecessary code. (Alternatively, you can use a Web-based Lynx viewer to get a sense of how your page performs in a text-only environment.)
The next sessions
Tuesday’s session was the first in a three-part series. Things I hope to cover in April’s CSS session include:
- CSS sprites for displaying images and reducing HTTP requests
- More cross-browser fixes, including IE conditional comments
- Different stylesheets for different media, including print stylesheets
Further down the road:
- Emerging CSS3 techniques, such as border-radius, text-shadow, and box-shadow
- A strong focus on progressive enhancement — show an awesome page to awesome browsers while making a site perfectly attractive on older browsers
- Minifying CSS for fastest performance
Check back here or at chscowork.org for more information and timing on these and other after-hours sessions at Charleston Co-Working. I hope to see you there!
