One of the wonderful little things about a weblogging system such as TypePad or MovableType (and many others, of course) is that there are a lot of nice little usability touches that make it so much easier than having to work with all the HTML code yourself. Rather than mucking around with “ tags and the like, you just type away, and when you hit “Post”, all those niggling little details are taken care of for you.

Every so often, though, something doesn’t quite work the way you’d expect it to. Over the past few days, a few people have been posting in a thread on the TypePad User Group, trying to figure out why every so often, using the <blockquote> tag would suddenly cause display issues in a finished post.

Since I’d had to battle with this in the past, I ended up writing a small book attempting to explain just what was going on. My full post (in my usual overly long-winded style) follows.

After reading through this thread, I believe I’ve seen a couple different things going on when dealing with blockquote elements. I’ll see if I can clearly (if not terribly concisely) toss some useable answers out. ;)

I’ll start with an easier one to explain. I saw this from BJ:

It seems the problem occurs when the blockquote is within a paragraph:

<p> blah blah <blockquote> quoted stuff </blockquote> More Stuff </p>

There are a few types of tags in HTML. In this case, we need to know about two types: inline tags and block level tags.

Block level tags define a chunk of HTML code or text that is a self-contained block (I hate using a word to define itself, but that’s all I’m coming up with right now). A paragraph is a good example of this type of tag. Inline tags define a chunk of code or text that is contained within a block level tag — for instance, bold or italic text inside a paragraph.

The simplest way to visualize this is simply visualizing how a paragraph is structured: you can have bold and italic words inside a paragraph, but you can’t have paragraphs within bold and italic words, nor can you have a paragraph within a paragraph. In other words, this is a valid structure:

<p>Well, isn't <i>that</i> just absolutely <b>nifty</b>!

But this isn’t:

I'm not sure what to use here <p>as an example</p>, so I'll make something up.

Now, as long as all that made sense, all you need to realize is that a blockquote, as implied by its name, is a block level element, and therefore cannot be used within a paragraph. A properly formatted blockquote should look something like this:

I found this interesting little bit of information today:

<blockquote>A really interesting bit of information.</blockquote>

See? Pretty cool, huh?

If you want to correctly code an inline quote, as in BJ’s example, you should use the <quote> HTML tag, like so:

blah blah <quote>quoted stuff</quote> More Stuff

Okay, done. And that was the simpler of the two situations!

The second (and probably the one that’s biting the most people in the butt) is the bizarre linespacing issues that crop up at times when using the blockquote element. Sometimes blockquotes work fine, sometimes they’ll go tweaky within the blockquote, and sometimes they’ll affect things after the blockquote is closed.

I struggled with this for a while myself, but I eventually figured out that the culprit is actually one of the things that TypePad (and MovableType, for that matter) does to help us out: the automatic wrapping of paragraphs in paragraph tags (the “convert line breaks” option in the ‘Text Formatting’ menu).

TP/MT determines where to place paragraph and linebreak tags by looking at the text of the post: a single carriage return becomes a linebreak (<br />); blocks of text surrounded by two carriage returns (blank lines) get surrounded with paragraph tags (“…</p>). Simple enough on its own, but TP/MT also scans for certain other tags, and when it encounters those, it does not insert paragraph or linebreak tags. I don’t know all of the tags that will trigger this, but I know that list tags and blockquote tags are definitely in the list.

Now, when a blockquote is only a single paragraph, that’s not a problem at all. For instance, given the following text entered into a post:

I found this interesting little bit of information today:

<blockquote>A really interesting bit of information.</blockquote>

See? Pretty cool, huh?

TP/MT would output the HTML as follows:

<p>I found this interesting little bit of information today:

<blockquote>A really interesting bit of information.</blockquote>

See? Pretty cool, huh?

Where things get tweaky is when a blockquote contains multiple paragraphs. The first paragraph of the blockquote will be ignored as it should, but then the second paragraph of the blockquote gets an opening paragraph tag — and suddenly you run into a situation where two block level tags are fighting with each other. Then, when the blockquote ends, you have an opening paragraph tag, a closing blockquote tag, and then a closing paragraph tag — more confusion.

For example, given the following text put into a post:

I found this interesting little bit of information today:

<blockquote>A really interesting bit of information.

Some more information that's also interesting.</blockquote>

See? Pretty cool, huh?

TP/MT will wrap the first line in paragraph tags. Because the second line begins with a blockquote tag, it will ignore that line. As the third line begins with normal text, TP/MT will wrap that entire line in paragraph tags, which is where the weirdness creeps in. Here’s how the output would look:

I found this interesting little bit of information today:

<blockquote>A really interesting bit of information.

Some more information that's also interesting.</blockquote>

See? Pretty cool, huh?

Once you factor in CSS declarations into all of this, which might have differing settings for blockquotes and for paragraphs, you can see why things end up getting more than a little wonky as your browser tries to work its way through the tag soup and figure out how to format everything.

(ADDED: By the way, I should clarify that while both paragraph tags and blockquote tags are block level elements, different rules apply to them: while you cannot have a blockquote contained within a paragraph, you can have a paragraph [or multiple paragraphs] contained within a blockquote. While this may seem a little confusing from a “but they’re both block level elements!” standpoint, from a logical and English usage standpoint, it does make sense. I just can’t explain it any better than that. ;) )

There are two ways to get around this, neither of which are incredibly complex — but neither of which are incredibly easy, either.

The first is simply to switch the ‘Text Formatting’ option to “none” and type in all the paragraph tags yourself so that TP/MT doesn’t have to do it automatically. It works, but it also takes away from some of the ease of use of TP/MT.

The second option (and the one I use) is to keep in mind how TP/MT will interpret what you give it, and do a little bit of manual work to get around the issue. You’ll still be doing some manual work with tags here, but not quite as much as you might in option one. When I’m entering a two (or more) paragraph blockquote into one of my posts, I simply take into account the extra tags that TP/MT will add, add a couple of my own, and then ‘push’ a couple lines together so that the resulting code will output correctly after it passes through TP/MTs routines.

This is a bit easier to show than to describe, so — starting with the above example again, here’s the starting point:

I found this interesting little bit of information today:

<blockquote>A really interesting bit of information.

Some more information that's also interesting.</blockquote>

See? Pretty cool, huh?

Now, to prevent TP/MT from munging things up, I would put that example into one of my posts like this:

I found this interesting little bit of information today:

<blockquote>A really interesting bit of information.

Some more information that's also interesting.</p></blockquote>See? Pretty cool, huh?

Now TP/MT has only three lines to work through. As before, the first line gets wrapped in paragraph tags. Because the second line begins with a blockquote tag, it gets ignored, but as I’ve manually added paragraph tags, that’s fine. The third line, like the first, gets wrapped in paragraph tags because it starts with simple text, but because I put in the requisite paragraph tags on either side of the blockquote tag, all the tags in the resulting code balance out, like so:

<p>I found this interesting little bit of information today:

<blockquote>A really interesting bit of information.

Some more information that's also interesting.</p></blockquote><p>See? Pretty cool, huh?

And (finally), that’s that! I realize that it’s probably fairly daunting at first, but after playing with it a bit, I think it should start to make sense. Maybe. ;)

Anyway, those are the two major issues with blockquote elements that are probably causing frustration for people.

And that’s far more than enough babble from me on all this. Hopefully some of this helped some of you — as always, if I just managed to make things more confusing, feel free to post followup questions, and I’ll do what I can to clarify!

One of the constant topics that many webmasters and webloggers are concerned with these days is Google, how to increase your site’s standing in Google’s eyes, and therefore drive more traffic to your site. I use a number of techniques on my weblog, both in the code and how I create entries, that help Google get the most useful information out of my pages.

While I’ve mentioned some in the past, the subject recently came up in a thread on the TypePad User Group, and I shared some of my methods in that thread. At the request of both Liza and Richard, who have also been posting about this topic, I’m re-posting my post (post-haste, though not post-mortem, and definitely not postpartum) here…

Still, I’m amazed to read that you had 1,000 per day BEFORE MS made you a web celeb (boo! to them). Do you think those hits came from your blogging subject or from special tactics you engaged in to increase your site traffic.

A little bit of both, probably.

First off, it’s not so much my subject, as my lack of subject. ;) Because I’ve never really focused on any specific topic for my blog, and just randomly babble about whatever crosses my mind, that gives Google a lot of potential keywords to pick up on.

Also, I’ve been at this for about three years now, so I’ve got a fairly large archive section, which also increases the probability of any given keyword turning up in a search.

As far as special tactics, there’s a few techniques I’ve picked up on over the years that seem to help (some of which you covered in your post).

  1. Descriptive headlines as a page title. The title of a webpage scores very highly in Google’s ranking scheme, so I generally try to make sure that my post titles are descriptive of what I’m posting about (“Lord of the Rings Trailer” rather than “This is cool!”), and I make sure that the post title is included in the page title.

    I believe that TypePad is set to include post titles in page titles for individual archives by default, but some weblog tools (including MovableType in its early stages, I believe, though I could be wrong) only include the site name for every page title, so instead of a site containing 1000+ differently named pages, you’d end up with a site containing 1000+ pages all named “My Weblog”, which doesn’t give Google nearly as much to work with.

  2. Setting a consistent structure for the code on each page. As HTML was designed to emulate (though not visually replicate) the structure of a printed document, it includes various structural elements such as various levels of heading. As Google pays attention to these when it scans a document, it often helps to use them correctly.

    In the past, rather than using the <h1>, <h2>, etc. elements for headlines, division markers, and so on, many sites would use <font> tags to give their subdivision headings the look they wanted. Now that the <font> tag has been deprecated and we can use CSS to style every element on a page the way we want, it’s good to return to using structurally correct markup. In addition to making a site much easier to code, it also assists Google in determining the structure, topic, and relevance of any given page.

    For each individual archive page on my site, I’ve structured it as follows:

    1. <title>: website name > post title

    2. <h1>: website name

    3. <h2>: website ‘tagline’

    4. <h3>: post title

    5. <p>: post body

    6. <h3>: trackback

    7. <h4>: trackback source

    8. <p>: trackback body

    9. <h3>: comments

    10. <h4>: comment author

    11. <p&>: comment body

    12. <h3>: comment posting form

    This gives each page a clearly delineated, easy to read structure that tells both the reader and Google which parts of the page are the most important and the most relevant to the topic of the page.

  3. Link descriptively. Simply, this involves using natural language for your links so that the link is descriptive to what it points to. For instance, saying “The new Lord of the Rings trailer is out!” instead of “You’ve gotta see this!” gives Google more information about what you’re linking to.

    This carries a double benefit, in that not only does it give Google better information about what you’re referencing, it also lets Google know more about what you’re linking to, which helps out whoever is on the target end of your link.

  4. Alt text on all images. This is important for a few reasons. First off, it lets Google know what each image is so that Google can include it more reliably in their image search feature. Secondly, though, and more importantly, it greatly improves the readability of your site for people with disabilities using specialized browsers to read the web.

    Blind users can use a “screen reader” to read websites — this is a specialized browser which translates the text to audio, and reads the page to them. Without alt text, all that screen reader can do is give them the name of the graphic, and might end up telling them something like “Image named funnypicture.jpg”. With alt text, they’ll instead hear something like “Image named Gimli falls off his horse”.

  5. Use the excerpt field to create useable descriptions. While keywords are no longer recognized by Google, another <meta> tag in the <head> section of your document still is (I think), which helps Google determine the topic of the page, and that’s the ‘description’ tag. What I’ve done is put this code into the <head> of each individual archive:

    <meta title="description" content="<$MTEntryExcerpt>" />

    I then make sure to take a moment to create an excerpt for each entry as I’m making it that relates to the topic of the post, rather than just relying on TypePad’s auto-generated excerpt (which generally just grabs the first n words of each post).

Anyway, there’s a few of the things I do which seem to help my site visibility. Mostly, though, I think a lot of it just boils down to the fact that after three years of babbling, I give Google a lot to work with. ;)

Earlier this evening, I got an e-mail from Pops asking me how I created the little tooltip-style comment text that appears when you hover over links in my posts. I ended up giving him what was probably far more information than he was expecting, but I also figured that it was information worth posting here, on the off chance it might help someone else out.

It’s actually a really easy trick, though not one built into TypePad. Simply add a title declaration to the link itself. For instance, if I wanted the text “Three martinis and a cloud of dust” to appear when someone hovered over a link to Pops’ site, I’d code it like this:

<a href="" title="Three martinis and a cloud of dust">Two Hour Lunch</a>

The end result looks like this (hover over the link to see the title attribute in action):

Two Hour Lunch

That little title attribute comes in wonderfully handy, too, as it can be applied to just about any HTML tag there is.

For instance, good HTML coding includes alt text for all images, so that if someone has image loading turned off in their browser, or if the image fails to load for any other reason, there will be some descriptive text to tell them what gorgeous vistas they are missing. However, in most browsers the only time that text shows is if the image doesn’t load. Using the title attribute in addition to the alt attribute when adding images, we can create that same style of comment when someone hovers over the image. For example:

<img src="lalala.gif" width="360" height="252" alt="NOTICE: I'm not listening!" title="La la la la la la!" />

That way, when displayed in the browser, if the image didn’t load, the text ‘NOTICE: I’m not listening!’ would show instead. In addition, the text ‘La la la la la la!’ will appear if someone lets their cursor pass over the image. Not a necessary thing, but it can be fun for quick, pithy little comments. Here’s the example:

NOTICE: I'm not listening!

Another place I use title tags fairly regularly is when I make changes to a post after it’s first posted. HTML includes two tags (<ins> and <del>, for insert and delete, respectively) for marking up changes to text. When I go back in to edit a post after it first appears on my site, I use those tags with a title attribute to indicate when the change was made.

For example, suppose I posted the following:

Pops is a screaming loony, who shouldn’t be allowed within twenty yards of anyone who isn’t equipped with body armor and a machete.

Later, coming to my senses, I could change that like this:

Pops is a <del title="7/30/03 10pm: I think I was on drugs when I wrote this.">screaming loony, who shouldn't be allowed within twenty yards of anyone who isn't equipped with body armor and a machete</del> <ins title="Here's what I meant to say...">great guy, whose website has pointed me to some fascinating tidbits on a regular basis</ins>.

(I hope Pops doesn’t mind the sample text here.) ;)

On screen, after the update, the deleted text would display as struck through, and the inserted text would display underlined (standard editing notation), with the comments displaying on a cursor hover, like this:

Pops is a screaming loony, who shouldn’t be allowed within twenty yards of anyone who isn’t equipped with body armor and a machete great guy, whose website has pointed me to some fascinating tidbits on a regular basis.

So there ya go — more information on the humble little ‘title’ attribute than you probably ever wanted or needed to know. I hope it helps!

Update: (See? There’s a title attribute right there!) As of this writing, the title attribute is barely supported in Apple’s new web browser, Safari. Titles on links will appear in the status bar at the bottom of the window if the status bar is turned on, but that’s it. No other title text will be visible. I’m hoping that this is fixed in a later update to Safari, but for the moment, that’s what we have to work with.

Up until now, all the various design tweaks I’ve made on this site have been conducted from within the TypePad interface, without my mucking about with any of the code. That’s starting to change, however, as I start to incorporate some of the conventions I’ve gotten used to with my templates at The Long Letter into the site here. I’m taking things a little slowly to make sure I don’t break anything (permanently), but work has begun.

Some details and thoughts on my changes follow.

(The following notes will be updated as I work my way through the various templates and make my changes.)

All templates

Two minor changes have been made to all the templates.

The first is purely cosmetic, in that I’ve adjusted the indenting of all the HTML code so that it’s easier for me to track through. As a side benefit, it should be a bit easier for other people if they go poking around in my source code.

Secondly, and important for usability, I’ve noticed that in the default templates, none of the hyperlinks have the title attribute set (the text that shows as a tooltip in most browsers, or before the URL in the status bar in Safari). I was somewhat surprised by that, but it’s a fairly simple fix for most of the tags.

Archive Templates (category and monthly)

The default templates for archives display every post in its entirety in reverse chronological order (exactly which posts are displayed depends on the archive type — all posts in a single category for category archives, all posts in a month for monthly archives, etc.). That may work well if you create short posts, or don’t post terribly often, but for me, it’s a nightmare. I tend to babble and create (ridiculously) long posts, and while this site is new, if I do end up adopting TypePad for my permanent home once it’s open for business, then I’m going to want to import all two years plus of my archives. Obviously, with the default templates, this could make for extremely long archive pages.

So, to combat that, I set up my archive templates to create essentially a ‘table of contents’ for each archive page. Each archive page now displays the title of each individual post, linked to the post’s individual entry page. After that comes the post excerpt, then a brief listing of the post’s metadata (post time and whether any comments have been added — were I creating a multi-author weblog, post author would be included also).

With this setup, while each archive page will still grow over time, it will be substantially smaller than it would be if it were displaying the entirety of each post. By including the post’s excerpt, it allows for a little more contextual indication of what each post is about, so it should still be relatively easy to find individual posts.

Currently (as of 8:20pm, July 13th) I’ve only altered the category templates to reflect this scheme, but monthly archives should be updated shortly.

7/13 8:54pm: Monthly archive pages have also been updated.

Archive templates (individual)

Not too terribly many changes here, aside from the aforementioned HTML re-formatting and adding title attributes to the hyperlinks. I did tweak the post metadata line so that the permalink is attached to the timestamp on the post rather than a single word that just says ‘Permalink’, and then added permalinks to individual comments with the same style. Other than that, it’s primarily the same.

I would eventually like to see if the live comment preview I have working on my individual pages on The Long Letter will work in this layout, but I’ll probably save that for another night, just in case it turns into more of a battle than I think it will.

Main index template

Again, like the individual archives, not too many changes — primarily just the formatting of the metadata line, with permalinks moved to the post time. Not that exciting, overall.

Main archives template

The default main archive template is functional, but nothing more than that. A simple list of links to the monthly archives, with links to category archives (if you’re using categories) below that. Not bad, of course, but I wanted to do better.

The monthly archive links I’ve kept more or less the same, with the exception that rather than listing out one on top of the other (and using up a large amount of vertical space for very little information), they list out horizontally. Of course, you can’t really tell that now, but when we roll around to August it’ll be more obvious.

For the category archives, I’ve included the post titles to the last ten posts in each category beneath the category title. The title itself links to the full category archive page, while the post titles link to their respective individual pages. It’s not much more information that what was available before, but it does give a little bit more, and can make searching for a recent post a little quicker than digging through each archive page if you don’t quite remember what category it got tossed into.