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!

The three big reasons why Chrome reigns supreme? Speed, more speed, and WebKit. And now that extensions have come over to the Mac, there’s not too terribly many reasons to stick with Firefox anymore.

How I Beat Browser Inertia

I don’t change browsers easily. It took a popup blocker and Microsoft’s neglect of the platform to pull me away from Internet Explorer in early 2002 toward Mozilla 1.0, which I came to really enjoy as a solid, customizable browser that made the Web look quite a bit better than Internet Explorer could show me. I used the Mozilla Suite for several months until the Phoenix project started; this project broke the browser out of the suite as a standalone application, and was very speed-focused. This project, of course, became what was eventually released as Firefox. As I didn’t need the rest of the cruft of the Mozilla Suite (indeed, before Phoenix/Firebird/Firefox came around, I would install just the browser component), Firefox was a perfect fit, and has been until very recently.

Then, Chrome for Mac started to really ramp up and take shape, and I knew it was worth another look. I installed it and was immediately taken by its speed and reliability. Chrome launches quickly, is a Mac-native application (Firefox actually fakes a great deal of the Mac OS X user experience which leads to many different penalties, including performance), and can handle the load of 15 to 20 tabs incredibly efficiently — something I absolutely rely on in my work. JavaScript is very speedy — Google Wave is almost usable! — and Chrome seems to be a bit ahead of Firefox in terms of CSS 3 and HTML 5 support. The WebKit rendering engine Chrome uses is the same as the one in Safari, but Chrome is a much more stable application than Safari and will probably have a much greater reach as a result. WebKit is important, as it’s suddenly poised to be the dominant rendering engine of this decade, primarily because of its impact on the mobile market — the iPhone and Android OS both use a WebKit-powered browser. The proliferation of Google Chrome and the Google Chrome Frame for Internet Explorer suggest that Mozilla’s Gecko engine could be in trouble. So, Web developers: ignore WebKit-based browsers at your peril.

Caveats for Developers

WebKit also comes with an extensive set of developer tools, but the version in Google Chrome still seems buggy to me. I also don’t like that the developer tools pop open in a new window — when working on the road without an extra monitor, it becomes somewhat inconvenient to flip windows back and forth (especially on a small 13″ screen). A pane view — like Firebug, or even Safari’s developer tools — would be more effective. Occasionally, I do find myself starting Firefox in development sessions for the express purpose of using Firebug on troublesome pieces of code. Firebug still works the best of all the debuggers out there.

Extensions

I didn’t start gathering extensions until a few days ago, as Chrome for Mac only very recently got extension support. The two must-haves that I’ve identified so far:

• Type-Ahead Find, an implementation of Firefox’s find-as-you-type feature for Chrome. This lets you simply start typing in a Web page to find phrases — really a great feature, and something I missed initially coming over from Firefox.
• RSS Subscription Extension, which fixes the startling omission of a lack of any RSS discovery/reading features in Chrome. I’m not quite sure why this wasn’t included by default, but I’m glad Google’s developed an extension to remedy this for those who use this feature (such as myself).

Other extensions I’ve installed include a handler to open mailto: links in Gmail and a window resizer — a critical tool for any Web developer’s toolkit. Other than that, though, the core feature set of Chrome is serving me well. Will it serve me for the next several years? Time will tell, but I know one thing: I would have a very tough time switching back to Firefox if I had to.

We had ten minutes to talk (and I know I went over!), so this presentation scratches the surface of the surface on the topic. It’s geared — as best as I can! — to a non-technical audience, so the geeks of the audience may be disappointed. If you have any questions or comments about my presentation, please feel free to leave a comment on this post. Thanks to AdFed Charleston for the opportunity to be a part of what is an excellent series. Follow AdFedCharleston on Twitter to keep up with future seminars and events.