February 2011 Update: This post was originally published in 2007 and hasn’t aged well. For code snippet syntax coloring, I currently use Google’s Prettify script (prettify.js). The script is dynamically inserted by jQuery if there are code elements to style.

Recently I’ve been experimenting with two very different methods of syntax coloring source code in web pages. The first method uses a Dan Webb’s CodeHighlighter JavaScript library to convert appropriately tagged content into syntax colored code. It’s necessarily simple, but easily extensible. As an example, here are the CSS rules I’m using to style CodeHighlighter’s conversions:

code.html span.comment         { color: #999;}
code.html span.tag             { color: #07f;}
code.html span.string         { color: #080;}
code.html span.attribute     { color: #07f;}
code.html span.doctype         { color: #07f;}

code.css span.comment          {color: #999;}
code.css span.keywords         {color: #fd2;}
code.css span.selectors        {color: #0b0;}
code.css span.properties    {color: #66f;}
code.css span.units            {color: #33c;}
code.css span.urls            {color: #4a0;}

code.javascript span.comment     { color: #999; }
code.javascript span.brackets     { color: #07f; }
code.javascript span.string     { color: #4a0; }
code.javascript span.keywords     { color: #07f; }
code.javascript span.exp         { color: #808; }
code.javascript span.global     { color: #06e; }

The second method uses two more fantastic TextMate features, Create HTML From Selection and Create CSS from Current Theme. What these two commands do is translate exactly what I’m seeing in TextMate into very precise and valid XHTML with accompanying CSS rules. The main disadvantage of this is the weight of the code, the above 721 bytes of CSS converts to nearly 36k of HTML and CSS rules. It’s a seriously heavy pile of span tags, but the cost is immediately outweighed by 148 very specific reasons. And that’s just bundles, there are dozens of great themes too.

Aaron Quint also deservingly gushes over these two commands.

What these do is convert exactly what I’m seeing in TextMate into very precise and valid XHTML. Here’s the same CSS as above translated by TextMate:

code.html span.comment      { color: #999;}
code.html span.tag          { color: #07f;}
code.html span.string       { color: #080;}
code.html span.attribute    { color: #07f;}
code.html span.doctype      { color: #07f;}

code.css span.comment       { color: #999;}
code.css span.keywords      { color: #fd2;} 
code.css span.selectors     { color: #0b0;} 
code.css span.properties    { color: #66f;} 
code.css span.units         { color: #33c;} 
code.css span.urls          { color: #4a0;} 

code.javascript span.comment    { color: #999;}
code.javascript span.brackets   { color: #07f;}
code.javascript span.string     { color: #4a0;}
code.javascript span.keywords   { color: #07f;}
code.javascript span.exp        { color: #808;}
code.javascript span.global     { color: #06e;}

Just for the sake of comparison, below is a screenshot of how my code looks in TextMate. It’s not a perfect translation, but it’s a very good start:

One of the purported advantages of the JavaScript method is that the source code remains unchanged. That’s sort of true, but not really. The JavaScript functions work by inserting a bunch of spans, so by the time the user sees it the main difference between JavaScript converted code and pre-processed code from TextMate is the detail (and weight) of the TextMate result. Also, any HTML would need to have entities escaped which is another step and a further degradation of the original code.

The main advantage then becomes convenience. A simple block of code doesn’t need to be run through TextMate (on the off-chance I’m writing somewhere else), it can be entered directly and tagged for styling without breaking focus.

Recently, I’ve spent some time working with MediaWiki for Lila’s school’s web site. A small part of what I’ve been doing has been implementing an exisiting design onto the wiki backend. In an effort not to overcomplicate anything (think longevity) I built the entire design adaptation on the default MediaWiki MonoBook theme. Everyone who’s visited Wikipedia has seen what this looks like. Monobook is a very well constructed theme with clearly defined parts that degrade nicely without its stylesheets. So far, with the exception of these two small changes, I’ve able to do everything I needed to with the default page structure.

First change: Fixing bad portlet IDs

Editing Mediawiki:Sidebar allows for nearly complete customization of the sidebar links. Custom sections automatically get custom IDs which can then be styled. There is one thing that seems like a bug however: If a section heading has a space in it, the portlet ID will have an illegal name. Classes can have spaces in their selectors, but IDs can’t. Here’s what I did:

<div class='portlet' id='p-<?php echo htmlspecialchars($bar) ?>'>

and the new one:

<div class='portlet' id='p-<?php echo str_replace(' ', '_',htmlspecialchars($bar)) ?>'>

Simple enough, PHP’s str_replace is used to swap underscores for spaces. I’m still feeling my way around the MediaWiki codebase, so this might not be the best solution to the problem, but it does what it needs to with a very lightweight function.

Second change: Classes from page title

I needed to change the background of the globalWrapper element depending on the page, the way I accomplished this was to use the page-title. This has one initial drawback, namely that colons are not allowed in CSS class names. However the workaround above can be recast here with added benefit. Switching colons for spaces results in multiple class names, so namespaces can be styled too.

Here’s the old code:

<div id="globalWrapper">

And the new code:

<div id="globalWrapper" class="<?php echo str_replace(':', ' ', $this->data['titleprefixeddbkey'])?>">

This method would seem preferrable to adding a CSS import rule which would look for a custom-named file. Even though CSS load errors don’t break pages with visible 404 errors, they would slow down page loads and litter the server logs. Checking that the CSS file exists is somewhat costly, and I suspect MediaWiki’s cacheing isn’t something that can be quickly skimmed over and implemented.

There appears to be a pageCSS extension somewhere, the hooks are even specified in MonoBook’s header, but I couldn’t find a working download and CVS repository doesn’t seem to be working anymore.