blockquotes in TypePad and MovableType

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!

ecto beta available

The creator of blogging client Kung-Log has rewritten, updated, and renamed it, and has just relased the first public beta of ecto, which I’m playing with now. While I was never completely pulled in by Kung-Log, ecto so far seem to be fairly impressive. Quick response time, supports about everything I’d want it to (trackback pings, categories, file uploading, etc.), and has a decent number of useful extras (an option to prevent uploading posts that don’t have a category set or a summary written, and a live preview that can even tie into your site’s stylesheet so that it actually looks the way it should once posted), plus some “fun” goodies (like the ability to automatically insert what track iTunes is currently playing).

I’ve gotten so used to just using the web interface that I’m not entirely sure if I’ll be coaxed away from that or not, but I’m always willing to give one of these things a try. We’ll see how it goes.

(via Lane)

iTunes: “Difficult Listening Hour – 02v2” by DJ Wüdi from the album Difficult Listening Hour (2000, 1:04:41).

:hover support in IE!

Hot damn — someone figured out [how to hack :hover support into Internet Explorer]! If I get some time this weekend, I’ll muck around with it until I can get it working on my site — one more step towards a consistent, cross-platform, standards compliant design.

(via Eric Meyer)

I used to be a DJ / Gig’s Music Theater

Some of my long-time readers (and family and friends) will already know that prior to moving down to Seattle, I spent around eight years of my time in Anchorage DJ’ing for a number of dance clubs. From City Lights, to The Lost Abbey, to Gig’s Music Theater, to The Eclipse, and finally to Studio 99, I spun practically every possible genre — alternative, industrial, punk, goth, 80’s retro, new wave, disco, swing, techno, house, trance, and even (though I grumbled a lot) the occasional top-40 and R&B — and had an absolute blast doing it.

I finally got tired of letting my old domain sit inactive after moving my weblog to TypePad, and have resurrected djwudi.com as a monument (however small) to my years as a club DJ. In addition to some oddly third-person ramblings about my career, there are no less than (though no more than) eleven different mix sessons posted and available for either download or streaming audio listening. Ten of them are even worth listening to — the eleventh (Difficult Listening Hour 03) has some truly horrendous trainwrecking going on, and I only leave it posted out of my anal-retentive need for a complete set.

Anyway, feel free to stop by, download or stream the mixes that are there, and (hopefully) enjoy! Who knows — I may not have a club gig anymore, but since I’ve still got my equipment and a ton of music, there’s always a slim chance that there may be more in the future…

As an added bonus, I’ve resurrected the last archived version of the Gig’s Music Theater website that I maintained for the club. This archive dates from March 30, 1998, and serves both as a nostalgic remembrance of one of the best all-ages clubs in Anchorage’s history, and as a monument to my web design and coding skills at the time. ;) Hopefully some of Gig’s old patrons might get a kick out of this (especially the pictures in the ‘Scene’ section)! I also have an archive of old flyers for Gig’s that I made, though I’ve mentioned those before.

Blog of the Month

This was nice — I got picked as “Blog of the Month” by AndrewBlog:

This is a beatiful blog with amazing content and a superb layout. Michael Hanscom is bringing blogging to the next level with this site. He has a firm commentment to his blog (this is the guy whogot fired from Microsoft for his blog).

Thanks, Andrew!

TypePad User Group

It’s plug time!

I’ve been hanging out on the TypePad User Group for a while now. It’s a great little resource for TypePad users — entirely unofficial, but a good place to go as a first resource for figuring out issues with coding and maintaining TypePad weblogs.

We’ve noticed that while there are a lot more TypePad weblogs popping up, it’s lost some of the “community” feel that it had in the beta test days, and it was suggested that…well, I’ll let authenticgeek speak for himself:

I think this forum is an awesome place to get info about TypePad.

>

There is just one small problem, TypePad is growing at such an huge rate and we’re not getting as many new users as we should be. Sure, it’s not a requirement to show up here if you’re on TypePad but I think there are people out there that should know about this place that don’t.

>

Any ideas for how we can better get the word out to new TypePad users? We could even talk to Ben/Mena about possibly getting an official link here from the TypePad site since I’m sure they don’t have the time to answer so many little questions about CSS and whatnot.

>

I’m going to make another post on my blog to remind people (the few who read) about this place. I urge other members (especially people with massive hits ahem djwudi…) to do the same and submit any other means for spreading the word.

See? They just want me for my potential hit-generating ability…;)

All joking aside, it is a good place to go for information, questions and answers. Feel free to drop on by.

Some slight design tweaks

I’ve done a little light fiddling with the design here in order to clean up some details that had been bugging me.

I started by adding a light grey background to blockquote elements in order to make them a bit more distinct from my babbling. That ended up making the page feel a bit heavier than I wanted, though, as the lightest grey I could use was the same grey that made up the background color in the lower section of each post’s title bar.

After fiddling with a few different approaches, I finally decided to use a slight gradient rather than a solid grey for the title bar, starting darker on the right and fading to white towards the left. The blockquote elements still felt a bit much, though, so I ended up creating a second, lighter gradient to use for their background as well. I’m not entirely sure I’m satisfied with the end result — while I like each effect individually, I’m not as sure about how they interact with each other on the page. Still, it’ll do for now.

Left and right floating elements (such as pictures and Amazon item links) have been nudged a few pixels outward in order to better align them with the outside borders of the post title bars.

Lastly, I removed the grey background behind the post titles and replaced that with a drop shadow effect behind the title text. The one downside to this approach is that it’s currently only visible in Safari (I believe), as Safari’s currently the only browser (that I know of) that supports that particular CSS attribute. The rest of you just need to upgrade. ;)

Safari bug: Amazon Associates Build-A-Link

Safari/Amazon bug screenshot

I’ve been noticing a bug in Safari over the past few days, and finally figured it was worth writing up and seeing if this is a “just me” thing or not.

I just recently started using the Amazon Associates Build-A-Link tool to create the product boxes for certain items that I talk about (like the one for Season 7 of Deep Space Nine in this morning’s post). Unfortunately, once I find the item I want to create the product box for, when Amazon sends me the page that is supposed to give me the appropriate HTML code to copy and paste into my entry, the textarea field is blank. In order to get the code, I’ve either been using Internet Explorer (shudder) or just viewing the source code for the Amazon page and digging through until I find the code snippet in question.

The code in question is found about 80% of the way down the source code. Here’s the relevant section of what Amazon sends, with what I should be seeing in that blank box on line six:

<tr>
  <td>
    <form name="snippet_form">
      <center>
        <textarea name="snippet" rows="7" cols="35">
          <iframe marginwidth="0" marginheight="0" width="120" height="240" scrolling="no" frameborder="0" src="http://rcm.amazon.com/e/cm?o=1&l=as1&f=ifr&t=djwudicom-20&p=8&asins=B00008KA57&IS2=1&lt1=_blank"><MAP NAME="boxmap-p8"><AREA SHAPE="RECT" COORDS="14, 200, 103, 207" HREF="http://rcm.amazon.com/e/cm/privacy-policy.html?o=1" ><AREA COORDS="0,0,10000,10000" HREF="http://www.amazon.com/exec/obidos/redirect-home/djwudicom-20" ></MAP><img src="http://rcm-images.amazon.com/images/G/01/rcm/120x240.gif" width="120" height="240" border="0" usemap="#boxmap-p8" alt="Shop at Amazon.com"></iframe>
       </textarea>
        <br />
        <input type="image" style="margin: 3px;" src=http://g-images.amazon.com/images/G/01/associates/build-links/highlight_html.gif name="highlight" onClick="javascript:this.form.snippet.focus();this.form.snippet.select(); return false;"/>
        <p style="margin: 5px;"><font face="Verdana, Arial, Helvetica, sans-serif" size="-2">Paste all the HTML into your Web site's HTML.<br /> Note: your tracking ID, <strong>djwudicom-20</strong>, is already embedded in the HTML.</font></p>
      </center>
    </form>
  </td>
</tr>

My immediate guess is that because the code ends up looking as if it’s requesting an iframe inside a textarea, Safari is just discarding what it sees as “bad code”. Unfortunately, as placing code inside a textarea is a fairly common way to avoid issues with long text strings that muck up a page’s layout (such as, well, this very post), that behavior effectively breaks the Amazon tool.

I’ve submitted a bug through Safari’s bug reporting feature, but I figured sending a TrackBack ping to Dave of Surfin’ Safari couldn’t hurt, either. ;)