Friday, April 10th, 2009

Lighter.js – Syntax highlighting for MooTools

Category: MooTools

If you’re a coder who likes to blog a lot, you know the value of a good code syntax highlighter. It helps to draw attention to your code snippets and sets them in a context easily identifiable to anyone who has used a code editor. José Prado came up with a MooTools-powered extension called Lighter.js that provides this capability.

Implementing the highlighting is very easy to do by creating a container element around the code to be highlighted and uniquely ID’ing it so that the container can be found via MooTools built-in DOM traversal factory method $(). You can see an example here:


  1. // Object style syntax with files in same level as html document.
  2. var myLighter = new Lighter('jsCode', {altLines: 'hover'});
  4. // Element style syntax with files inside of a folder called "js".
  5. $('phpCode').light({
  6.    altLines: 'hover',
  7.    path: 'js/'
  8. });
  10. // Highlight all "pre" elements in a document.
  11. $$('pre').light({altLines: 'hover'}); uses a code highlighter as well so if you compare the code above to the screencap below, you can see the similarities. MooTools developers should find it very easy to output a concisely layed out code snippet.

There’s no official demo for the extension but you can actually see it in action on Jose’s project page since the code examples he references are actually highlighted by his extension.

Posted by Rey Bango at 12:17 pm

3.8 rating from 43 votes


Comments feed TrackBack URI

Can it highlight this example appropriately?
var x = 4;
var g = 2;
alert(x ++ /4/g);
for (var x = a in foo && “” || mot ? z:/x:3;x<5;y</g/i) {xyz(x++);}
Syntax highlighters are a dime a dozen in the web. I’ve yet to see one capable of highlighting ambiguous syntax such as these.

Comment by TNO — April 10, 2009

who codes like this derserves a non working syntax highlightning.

Comment by Aimos — April 10, 2009

Part of my example was taken from Waldemar Horwat’s discussion on ambiguous grammars and language implementations. If anything, such types of discussions deserve a competent syntax highlighter more so than vanilla scripts. If the JavaScript syntax is valid, is it too much to expect of a syntax highlighter to color it properly?
Another example. This time a little more realistic:
Many highlighter’s I’ve seen try to turn “/></” into a regular expression token.

Comment by TNO — April 10, 2009

Ajaxian ate my E4X:
x=<y><{‘x’} a=”n” /></y>;

Comment by TNO — April 10, 2009



Comment by Aimos — April 10, 2009

I personally like SyntaxHighlighter 2.0 better. It has a lot of cool features. Plus there is a Live Writer plugin that utilize this highlighter.

Comment by fredclown — April 10, 2009

@TNQ, I hear ya. Almost 100% of the time “syntax highlighters” are actually just regular expression wrappers. I can’t think of any other pure js lib that actually attempts to parse the js itself except for jslint.

Comment by ilazarte — April 10, 2009

I just love the clean OOP style in Lighter.js and the quirky Lighter analogies! Call me a fan!

@ilazarte: Result would be a highlighter that only supports JS, who needs that? If a parser can’t read your code, can other developers understand it easily?

Comment by digitarald — April 12, 2009

when i try used, i got one error:
“Flame is not defined”

Comment by GaQuay — April 12, 2009

I too like dp.SyntaxHighlighter although I don’t know where they got their name-spacing from. Is there any real advantage to this new library? I mean its just another person who decided to reinvent the wheel.

Comment by jhuni — April 13, 2009

Result would be a highlighter that only supports JS, who needs that?
Programmers who write non-trivial JavaScript code and would like to have a syntax highlighter actually work for the language.

If a parser can’t read your code, can other developers understand it easily?

I’m willing to bet they would understand it easier if the highlighter put the right colors in the right places. If the “parser” can’t read valid code, then the lib is broken and needs a replacement.
My point and I believe ilazarte’s point is that 99% of syntax highlighters rely solely on token matching with regular expressions without any real thought put into handling ambiguous contexts where completely different tokens can legally exist in the same position.

Comment by TNO — April 13, 2009

Leave a comment

You must be logged in to post a comment.