HOWTO: Bug Check Your Blog

Sometimes it can be really difficult to track down bugs that cause your blog to display improperly? especially when the issue is not something you did in your template, but a mistake or typo in an actual post or TypeList.

The other day a question came in via comment on the FAQ page. Richard Murray was experiencing an issue that caused the text size in his blog to display larger in Internet Explorer than in other browsers. Oddly, when I viewed the blog in IE, I wasn’t able to replicate the issue. Bud suggested that it might be related to using keyword font sizing rather than specifying font sizes in pixels (MT uses keywords such as xx-small, x-small, small, medium, large, x-large, and xx-large to describe font sizes and IE doesn’t respond well to these). But although that was a good guess, it wasn’t the answer either.

In the end, it turned out to be a pretty simple problem: an open tag in Rich’s code was causing all the text after the tag to display larger. I had a similar problem once when I failed to close a bold tag in a TypeList. The entire blog displayed in bold text until I figured it out, making it very difficult to read. This kind of error can be difficult to trouble-shoot. After all, one wouldn’t expect a typo in a TypeList to effect the display of an entire blog. I spent a lot of time digging around in my templates before figuring out where the problem was.

That’s why it’s a good idea not only to view your blog in all the major browsers, but to periodically run your site through an HTML validator. Here’s a list of resources you can use to make sure that your blog will display properly on all platforms and in all browsers.

Checking your template and page code:

The first two links here are services that you definitely should run your blog through every now and then to make sure it’s functioning properly for all your readers. I especially recommend using these after implementing any new hacks on your blog’s template code.

browsershots.org: This is a great service that allows you to view screenshots of your pages in different browsers, at different screen resolutions and with different plugins. Browsershots.org distributes the work of making browser screenshots among volunteer community members using a program to automatically make screenshots of web pages in their browser and upload the results to the server. So what you’re seeing is not a rendered guess at how your site will display? it’s an actual image of how the site looks on different platforms.

W3C Markup Validation Service: a free service that checks Web documents in formats like HTML and XHTML for conformance to W3C Recommendations and other standards. Type in your URL, and the W3C will check the code to insure that everything is ship-shape. This is the best tool to use to check for things like tags that haven’t been closed.

Now, before you panic at the results, let me step out on a limb and suggest that the W3C Validator is just a wee bit overzealous at times. It doesn’t like the way that TypePad encodes line breaks for instance and will suggest that you go in and hand edit all of those. Nah? they’re wrong, but they work. Another thing that it will almost certainly take you to task on is whether you’ve used alt tags on all your images. I strongly suggest that you do (you’ll get way a lot more traffic from google images if you use alt and title tags) but it won’t adversely effect the display of your blog if you don’t.

If you’re not deeply familiar with HTML, It’s a good idea after checking your code to read up on each of the items the Validator lists and make an informed decision as to whether you must, should or might want to make the changes. A blog that is in perfect W3C compliance is definitely going to look the way you want it to on any platform, but it’s also important to balance perfection against practicality.

My suggestion? If you really wanted to fix something like all of your line break tags, use the Search & Replace tool found at the top of your listed entries. IMPORTANT: be careful when doing a replace, because there is no undo. If you are making a replacement in many of your entries, you may wish to first use the Export feature to back up your entries. Also, be aware that the Search & Replace tool can change both text and HTML in your blog. If you replace a term used in any links on your blog it will break the links and you’ll have to go back and fix that by hand.

The W3C also provides a number of more specific tools for checking the compliance of your code.

The Basics – what you should run on all your web pages

The MarkUp Validator: Also known as the HTML validator, it helps check Web documents in formats like HTML and XHTML, SVG or MathML.

The Link Checker: Checks anchors (hyperlinks) in a HTML/XHTML document. Useful to find broken links, etc.

The CSS Validator: validates CSS stylesheets or documents using CSS stylesheets.

The above three can be used all-in-one by running the Log Validator. Unlike the others, this tool helps improve the quality of a whole site, step by step, by finding the most popular documents that need to be fixed in priority. Learn more about this method in the Web Standards Switch document.

Checking your RSS Feed

If you’re using the built-in feed that TypePad provides or running your feed through Feedburner, you won’t be likely to need these. But if you’ve created a comments feed or a feed for categories, you might want to run it through one or both of the following validators to make sure it’s functioning properly for all readers.

W3C Feed Validator: Check newsfeeds in formats like ATOM and RSS.

FeedValidator, works with RSS 0.90, 0.91, 0.92, 0.93, 0.94, 1.0, 1.1, and 2.0. It also validates Atom feeds. If the validator finds any problems in your feed, it will give you messages for each type of problem and highlight where the problem first occurs in your feed. If you’re unsure what a message means, click the "help" link next to the message for a fuller explanation.

Extra Credit: Checking Security, Backwards Compatibility and
compliance with Section 508 Accessibility guidelines

And finally, for those of you who want to achieve maximum usability, here are some further resources. I suggest starting by taking a look at Mark Pilgrim’s free online e-book, Dive Into Accessibility: 30 days to a more accessible web site. The book explains why you should care about making your blog more accessible, and how you can do so. From the introduction:

To answer the first question, I will present character sketches of five people: Jackie, Michael, Bill, Lillian, and Marcus. These people have several things in common:

1. They all have a combination of physical, mental, and technological disabilities which make it more difficult to use the Internet.

2. Although fictitious, they all represent real people with disabilities, and they use the Internet in ways that real people with disabilities use the Internet.

3. They all have difficulty reading your web site.

To answer the second question, I will present 25 tips that you can immediately apply to your own web site to make it more accessible. Although these concepts apply to all web sites, I will be focusing on implementation using popular weblogging tools. If you use some other publishing tool or template system, you will need to determine how to implement the tips in your tool of choice.

Each tip will focus on a single concept, explain the reasoning behind it, and show who will benefit once you implement it. This is why the character sketches come first, because they change the tone of the first question from "Why should I bother?" to "Who benefits?" Answer: "Marcus benefits." "How does Marcus benefit?" "Well, let’s look at that…" And so forth.

Don’t panic if you are not an HTML expert. Don’t panic if the only web site you have is a personal weblog, you picked your template out of a list on your first day of blogging, and you’ve never touched it since. I am not here to tell you that you need to radically redesign your web site from scratch, rip out all your nested tables, and convert to XHTML and CSS. This is about taking what you have and making it better in small but important ways. Jackie, Michael, Bill, Lillian, and Marcus will thank you for your attention.

Tools you can use to test your blog for security, accessibility and backwards compatibility:

WebXACT: a free online service that lets you test single pages of web content for quality, accessibility, and privacy issues.

Delorie Software provides a number of free services to the web community to assist web authors who wish to make their information available to the largest audience. These tools provide alternate ways of viewing your pages, so that you can ensure that your content is received properly by all viewers.

Lynx Viewer: See how this browser views your page

Search Engine Simulator: See what the search engines see 

Web Page Purifier: Restricts your HTML to published standards

Web Page Backward Compatibility Viewer: See what your page looks like without support for various features

HTTP Header Viewer: Make sure your server is sending the correct MIME headers for your files. 

HTTP Request Viewer: Find out exactly what your browser is sending to my server.

The government also provides a list of companies that provide 508 compliance software as well as further information on how federal agencies are working to eliminate barriers in information technology, to make available new opportunities for people with disabilities, and to encourage development of technologies that will help achieve these goals.

9 thoughts on “HOWTO: Bug Check Your Blog

  1. I just Googled this site and was looking for 508 Accessibility info and how I make my site complaint.

    I’m downloading Mark Pilgrim’s free online e-book. Thx for the help.

    Ken Savage

  2. Very minor quibble: IE6 handles font keywords fine. It’s only IE5 which has trouble, and it’s easily fixed with some conditional comments to load a IE5-specific stylesheet.

  3. Great overview. Very valuable. Thanks for sharing.
    I didn’t know browsershots.org … will check it out.

    Awesome … del.icio.us 🙂

Comments are closed.