Blogger: Convert Line Breaks Setting

This post has a few tips/warnings for posting code for display and code for use (i.e. Javascript) in a Blogger post when you have "convert line breaks" on.

Updates
30/01/2009 5:49:32 PM. I have since turned this setting off and am now reformatting all of my posts to contain valid HTML.
22/07/2009 10:21:16 AM. Updated text in this article to account for my previously turning off this setting. Added brief section on Syntax Highlighter alternative (that I would like to re-visit in the future in another post with more detail).

The Problem with Convert Line Breaks

Check this setting: Settings > Formatting > Convert line breaks. If it is set to yes, then each line break you insert into your post will be interpreted as a <br/>. In general, this good for WYSIWYG writing i.e. it is good for authors who don't want to write HTML by hand. I thought I was one of these recently, until I tried to do two things in particular:

• Insert some Javascript into my blog post. This was defeated because after Blogger replaced all line breaks with <br/>, the Javascript didn't work!
• Post some code into a text area. This was defeated because my carefully laid out code was mangled by Blogger replacing all line breaks with <br/>

Here are my work-arounds for these two issues.

Inserting Javascript

1. Make sure you use semi-colons to properly end Javascript statements. I am a Java programmer, so this comes naturally to me.
2. Remove all comments from the Javascript. You can leave in block comments if you wish (/* .. **/) because they are self enclosed, but you definitely need to get rid of single line comments (//) or the next step will break your code.
3. Remove all line breaks from the code. Replace them with a single space if you have kept in block comments. I use UltraEdit, so this is an easy find/replace (find all instances of ^p, replace with nothing). You could remove all the leading space too, though in my usage so far I have left leading space as is - so that if I need to put back the line breaks I still have easily readable code.

Post some code

Previously, I was posting code with HTML PRE elements, sometimes with colour. For example: <pre style="color: blue">Formatted code goes here..</pre>. The problem with this approach is that large amounts of code don't look good. The flow of an article is easily broken if the reader has to scroll past a large code excerpt to continue reading the text. If the code excerpt is large, it is generally easier for a reader to skip it first and come back later to read it through or c&p it.

To help with this, I wanted to try putting the code into a scrollable text area. It didn't work though.

The above is from my previous Blogger post, Dynamic text field prompts with Javascript

My current work-around (See the Syntax Highlighter section below.) One approach I tried is to use a combination of the DIV and PRE HTML elements. For example: <div style="width: 500px; height: 200px; background-color: a0ffff; color: 000000; font-family: arial; font-size: 12px; text-align: left; border: 3px solid 00000; overflow: auto; padding: 4px;"><pre>Formatted code goes here..</pre></div>.

Here is an example:

<script language="javascript" type="text/javascript">
<!--
  // Clear prompt from username field, if required.
  function clearUsernamePrompt() {
    var username = document.getElementById("username2");
    if (username.value == "Username") {
      username.value = "";
    }
  }

  // Set the prompt for the username field, if required.
  function setUsernamePrompt() {
    var username = document.getElementById("username2");
    if (username.value == "") {
      username.value = "Username";
    }
  }

  // Clear prompt from password field, if required.
  function clearPasswordPrompt() {
    var password = document.getElementById("password2");
    if (password.value == "Password") {
      password.type = "password";
      password.value = "";
    }
  }

  // Set the prompt for the password field, if required.
  function setPasswordPrompt() {
    var password = document.getElementById("password2");
    if (password.value == "") {
      password.type = "text";
      password.value = "Password";
    }
  }
// -->
</script>

<input type="input" value="Username" id="username2"
onFocus="clearUsernamePrompt();" onBlur="setUsernamePrompt();"/> <input
type="input" value="Password" id="password2" value="Password"
onBlur="setPasswordPrompt();" onFocus="clearPasswordPrompt();"/>

I can now post large code excerpts with a basic level of formatting such that the reader can easily scroll past the code and refer back to it when they are ready. If you look at the source If I still had Convert line breaks turned on, you would see that Blogger has still gone ahead and replaced my line breaks with <br/> elements, but that's cool - the HTML PRE element will render them just the same as line breaks.

This approach has one major draw-back though. With a real text area, you can put your cursor inside it and do a "select all" (control+a in windows/linux browsers, use that funky apple button if you are on a Jobs machine). With a DIV, you end up selecting all text on the page.

Tables

Problems also occur with this setting turned on when you insert TABLE HTML code in your blogger post, which is very nicely illustrated by The Real Blogger Status in Tables Are Very Sensitive To Gratuitous Line Breaks. Line breaks convert to <br/> elements which will do a very good job of screwing up your carefully adjusted table layout! The work-around suggested is simply to remove line breaks in your code.

MLA Wire's Blogger post Table Formatting in Blogger suggests another neat work-around: use a CSS class to hide <br/> elements. Insert the following code in your post: <style type="text/css">.nobr br { display: none }</style> then give your HTML TABLE element the nobr class name.

Convert Line Breaks?

In future, I plan to turn that setting off I have now turned that setting off and "code" my blog posts with HTML. Not a big handicap for me, since I am comfortable doing this. There are various WYSIWYG editors that can help too, letting you type in preview mode and copy and paste the resulting HTML when you are done. Unfortunately, I will have to go over all of my old blog posts and change them!

Also check out what The Real Blogger Status has to say about this setting in the following blog entry: Separate Your Paragraphs.

Syntax Highlighter

Added 22/07/2009 10:23:06 AM.

Now I am using an amazing Javascript solution by Alex Gorbatchev: SyntaxHighlighter. I love this solution for the following reasons.

1. It uses language specific syntax highlighting to best display my code - just see the example below.
2. It provides buttons to let readers "view source" i.e. plain text and print the code.
3. It works equally in IE (8.0.6001.18702), Firefox 93.5.1), Chrome (2.0.172.37), Safari (4.0.2) and Opera (9.64) - tested on Windows XP.
4. Look at the code below - I specified "js" as the language, but it has handled the HTML components properly as well.
5. I don't need to replace < and > with &lt; and &gt;.

There are some disadvantages though. In my opinion these are minor compared to what it gives me in return, but they should be considered.

1. Setup. You have to edit your Blogger template to import the Javascript and CSS files. Sometimes this can be tricky to manage and get the paths right.
2. Hosting. You have to find somewhere to host the Javascript, CSS and image files because Blogger won't let you upload the Javascript/CSS files. I host them on my Google App Engine site, but (just for Blogger) Alex allows you to refer to the files directly on his own site.
3. Screen space. I mentioned above that the advantage of using a scrollable DIV means that long code fragments take up small sections of the screen. SyntaxHighlighter code is relatively compact but big sections of code will still take up big sections of screen real estate. I have decided the cost is worth it. If required, I will use SyntaxHighlighter to demonstrate excerpts of code and provide links to more complete examples.
4. Processing time. Because SyntaxHighlighter is a Javscript API, all the processing is done on the client side every time they open/refresh a page. It means that the more (and longer) pieces of SyntaxHighlighter code I have on a page, the longer and longer it will take for the SyntaxHighlighter sections to be processed. At least the processing is done after the page has loaded - so the user will still see the code in "plain" PRE format until the Javascript has finished and re-renders it.