Code highlighting in Blogger's dynamic templates

I decided to update the style of my blog recently, and immediately fell in love with new dynamic blog templates. Navigation is easy, and the look is quite slick.

But, as usual, all shiny things have downsides. Since dynamic templates fetch content via ajax, long after the main page is loaded, "conventional" ways to highlight code snippets on page load don't work (and most code highlighting libs only use this method).

And, to make things worse, developers of dynamic templates haven't provided us with hooks to detect the moment of page change. Some brave souls ventured into the depths of template javascript, and some even found the place where user's code can hook to get article change event - but since it's not documented and google developers change the code constantly, this workaround tends to break every several months or so.

Currently, I use simple (as in "quick&dirty") workaround - I simply insert small piece of javascript code directly into each article source: 
<script>runCodeHighlighting()</script>
This code runs every time the article content is loaded, successfully triggering code highlighting. The only downside - I constantly forget to insert this snippet when creating an article, and spend several minutes wondering - "why my code is not highlighted?".

For actual code highlighting, I use awesome Highlight.js - it's extremely simple to use, features language auto-detection and superb API. To get it to work, you only need the following snippet of code inserted into html of your blog template (somewhere in <head>): 
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script>
<link rel="stylesheet" href="//yandex.st/highlightjs/7.3/styles/sunburst.min.css"></link>
<script src="//yandex.st/highlightjs/7.3/highlight.min.js"></script>
<script>
  function runCodeHighlighting() {
    $("code").each(function(i,c){hljs.highlightBlock(c)});
  }
</script>
P.S. Previously, I used Github's gists to embed code in my posts, but it seems that it is incompatible with dynamic templates - code doesn't show up completely.

Comments

Post a Comment

Popular posts from this blog

How to create your own simple 3D render engine in pure Java

Image
3D render engines that are nowdays used in games and multimedia production are breathtaking in complexity of mathematics and programming used. Results they produce are correspondingly stunning. Many developers may think that building even the simplest 3D application from scratch requires inhuman knowledge and effort, but thankfully that isn't always the case. Here I'd like to share with you how you can build your very own 3D render engine, fully capable of producing nice-looking 3D images. Why would you want to build a 3D engine? At the very least, it will really help understanding how real modern engines do their black magic. Also it is sometimes useful to add 3D rendering capabilities to your application without calling to huge external dependencies. In case of Java, that means that you can build 3D viewer app with zero dependencies (apart from Java
Read more

Solving quadruple dependency injection problem in Angular

Angular comes with built-in dependency injection and module management system, but it can get a bit tedious to use when your project grows. Especially if you use RequireJS alongside it (a must for almost any project) and also want to be minification-safe with all those dependency injections. Let's look at a simple example with one module that provides a value and another module that prints that value: // answer.js define(["angular"], function(angular) { angular.module("the.answer") .value("TheAnswer", 42); }); // main.js define(["angular", "the.answer" ], function(angular) { angular.module("main", [ "the.answer" ]) .run([ "TheAnswer" , function( TheAnswer ) { console.log(TheAnswer); }]); }); As you can see, to provide a single dependency to my code, I had to specify it in four places (highlighted in red) - first as RequireJS dependency, then as Angular module dependency,
Read more

Configuration objects in Scallop

It turned out that spreading type annotations throughout all the code in all places where options are requested is not a good idea. And, of course, it is prone to errors - who likes those type annotations? When using such option parsing libraries, users usually end up creating a big object with fields corresponding to each option: object Conf { var apples:Int = 0 var bananas:Int = 0 } // ... parsing options ... Conf.apples = parser.getOption("option name", ...) Conf.bananas = parser.getOption("other option name", ...) Sure, this works, and usually flexible enough - but why would anybody want to create such boilerplate? And by the way, nobody likes var's in their code :) So in Scallop , I needed to cut down that unnecessary repetition. There are several ways: Create a compiler plugin. The most powerful option. And the least enjoyable - even given the ease of installing a compiler plugin using sbt, I doubt that anybody will install compiler p
Read more