Out Of What Box?

This blog uses Alex Gorbatchev’s SyntaxHighlighter, by way of the SyntaxHighlighter Evolved WordPress plugin. It’s a great piece of work, but one minor problem had been nagging at me.

SyntaxHighlighter places alternating white and light gray backgrounds on displayed lines, as an aide to readability. However, when SyntaxHighlighter is configured for scrolling rather than text wrapping, these backgrounds don’t extend for the full length of the scrolling region. Slide the scrollbar below, and you should see a darker gray background on the right, instead of the alternating light gray and white bars that are visible in the original viewport:

Many GUI tools and APIs that I’ve used in the past incorporated some form of “stretchiness”. For example, a “stretchy” button widget might specify a minimum size—but, if more space is available after other components have been laid out, it will gladly stretch out to fill the remaining space. If there were a CSS equivalent for stretchiness, a good place to use it would be on the <span>s that display those alternating backgrounds in SyntaxHighlighter. However, I’d never encountered a “stretchiness” setting in CSS, and searching for it this time around didn’t bring me a different result. This time around, though, I asked for help.

StackOverflow user brianpeiris confirmed that what I was looking for doesn’t exist in CSS. He also provided JavaScript code to stretch the width of those <span>s to the full width of their parent. Unfortunately, this wasn’t the end of my story. For one thing, this JavaScript uses jQuery, but SyntaxHighlighter isn’t built using jQuery. Hence I had the choice of re-writing his solution, or incorporating jQuery into my SyntaxHighlighter plugin. (I chose the latter approach.) For another, the script needs to be run after the document is fully loaded. Farther below, a code snippet shows changes to SyntaxHighlighter.all() to handle this.

The JavaScript approach also required a minor update to SyntaxHighlighter’s CSS¹. SyntaxHighlighter zealously guards its style definitions with the !important flag, making attempts to override them from JavaScript fail. This was solved by changing shCore.css. The definition for width was removed from a large class block:

Old version

.syntaxhighlighter,
.syntaxhighlighter div,
.syntaxhighlighter code,
.syntaxhighlighter span
{
 /*... other settings not shown here... */
	width: auto !important;
 /*... other settings not shown here... */
}

into two smaller cascading blocks: One for .syntaxhighlighter span that omits the !important flag, and another block for the other three selectors.

New version

.syntaxhighlighter,
.syntaxhighlighter div,
.syntaxhighlighter code,
.syntaxhighlighter span
{
 /*... other settings not shown here... */

   /* This is the same large block as before,
    * except that width is now set in the blocks below.
    */ 

 /*... other settings not shown here... */
}

/* Everything except .syntaxhighlighter span still has !important */
.syntaxhighlighter,
.syntaxhighlighter div,
.syntaxhighlighter code
{
	width: auto !important;
}

.syntaxhighlighter span
{
	width: auto;
}

But there was more to come: As it turned out, the stripped-down example that I’d posted on StackOverflow didn’t exercise the CSS box model quite as much as SyntaxHighlighter does. When I adapted brianpeiris’s solution in live code, the script gave each line of text within a single container a slightly greater width than the line before it, with an interesting visual effect. (Notice that this box has a scrollbar, even though the contained text doesn’t seem to be wide enough to warrant one. Scroll to the right and note the background colors.)

I’ve already hinted at the underlying problem here: When the script adjusts the width of each content <span>, it needs to account for the space used by the line’s padding and margin. Otherwise, it uses a width that’s too large. The too-large width makes the containing <div> grow wider, so the next line has more width to fill…²

The version shown below fixes this. (It’s also been modified to run inside of the main SyntaxHighlighter jss file, shCore.js ):

fixContentSpans : function() {
    jQuery('.syntaxhighlighter > div.lines').each(function(){
        var container = jQuery(this);
        var scrollWidth = this.scrollWidth;
        var width = jQuery(this).width();
        var contents = container.find('.content');
        jQuery(contents).each(function(){
            var child = jQuery(this);
            var widthAvail = 
                scrollWidth - parseFloat(child.css("margin-left"))  
                - parseFloat(child.css("padding-left"))
                - parseFloat(child.css("padding-right"));
            var borderLeft = parseFloat(child.css("border-left-width"));
            // IE uses names (e.g. "medium") for border widths, resulting in NaN
            // when we parse the value.  Rather than trying to get the numeric
            // value, we'll treat it as 0. This may add a few additional pixels 
            // in the scrolling region, but probably not enough to worry about.
            if (!isNaN(borderLeft)) {
                widthAvail -= borderLeft;
            }
            child.width(widthAvail);
        });
    });
},

(Note: The standard SyntaxHighlighter style sheets don’t include padding-right settings for content lines. I added it to my version of shCore.css, for aesthetic reasons.)

A similar issue cropped up when the browser window is resized: Once again, the <span>s that paint the background colors weren’t being resized to fit the new layout. Adding a resize event handler in shCore.js fixed that problem. (The new version also shows how the new script is invoked in the document load event.)

Old version (reformatted for display) :

/**
 * Main entry point for the SyntaxHighlighter.
 * @param {Object} params Optional params to apply to all highlighted elements.
 */
all : function(params)
{
    sh.utils.addEvent(window, 'load', function() { sh.highlight(params); });
}

New version (reformatted for display) :

/**
 * Main entry point for the SyntaxHighlighter.
 * @param {Object} params Optional params to apply to all highlighted elements.
 */
all : function(params)
{
    sh.utils.addEvent(window, 'resize', function() {sh.fixContentSpans();});
    sh.utils.addEvent(window, 'load',   function() {sh.highlight(params); sh.fixContentSpans();});
}

Removing line numbers from the paste buffer

While I was under the hood, I made one other fix. As it’s currently written, shCore.js always produces the HTML for displaying line numbers, regardless of whether the line numbers will actually be displayed. (Turning off line numbers is implemented by making them invisible via CSS.) The performance impact of this is probably negligible, but there’s a side-effect that isn’t: When you copy one or more lines of code from the browser window, the line numbers (visible or not) are included in the copy. When you paste, you get something like this:

01. /**
02. * Main entry point for the SyntaxHighlighter.
03. * @param {Object} params Optional params
04. */
05. all : function(params)

I’ve changed shCore.js so that these invisible line numbers aren’t inserted into the DOM. With this change, copying from a SyntaxHighlighter display produces the program text and nothing but the program text.

Downloading

A new version of the SyntaxHighlighter Evolved plugin is available as a ZIP file. This is based on v. 2.1.0 of SyntaxHighlighter Evolved, which in turn incorporates v. 2.0.320 of SyntaxHighlighter.

¹ Most likely, this problem could also have been solved with a JavaScript change to force the !important setting into the element’s style. It didn’t seem !important enough to try this.

² This is running into the territory of the IE Box Model bug. I didn’t see a need to try to add a workaround for it; I doubt that many readers of this blog would be affected by that bug. (Actually, if I ever have grounds to say “many readers of this blog” with a straight face, I’d cheerfully add such a workaround.)