Out Of What Box?

Well, that was… interesting.

I’ve been working on improvements in SyntaxHighlighter‘s whitespace handling. My goal was to have whitespace presented exactly as it’s supplied within the original HTML. I thought this would be helpful on two fronts: First, it might fix a few minor display formatting issues that I’d found. Second, and of greater concern to me, I figured that if SyntaxHighlighter preserved whitespace well enough, then it would be OK to remove the Flash-based “Copy” applet from the toolbar. (I’m not sure, but my guess is that the Flash app was added because copying the code to the clipboard has been so problematic.)

I’ll admit that its removal is a mixed blessing: It’s not like it’s a bad thing, to be able to copy the code to the clipboard with one click of the mouse. But the Flash applet carries some baggage, too: It requires Flash (well, yeah); it adds to the overall footprint consumed by SyntaxHighlighter (especially when using Internet Explorer); and it doesn’t always work.

I don’t have a lot of details on that last one; then again, I haven’t sought details. But the problem could simply be that Flash 10 added new restrictions on the application’s access to the Clipboard, thereby breaking it for SyntaxHighlighter.

Maybe, maybe not. But if the traditional select-and-copy operation worked as expected, without loss of newlines or other whitespace, would there really be any further need to keep the Flash script? I didn’t think so either.

I think I can hear some of you snickering. No, I hadn’t ever gone down this road before. So, I’ve discovered that perfect whitespace preservation in HTML is not easy. It may not even be possible, even setting tab characters aside.

I’d hoped to come up with a broadly cross-browser-compatible scheme for preserving whitespace in the display and in the paste buffer. What I have is a combination of JavaScript and CSS classes that fake it pretty well (I think.) The key, of course, lies in using the CSS whitespace="pre" and whitespace="pre-wrap" directives in the appropriate classes. JavaScript is needed, among other things, to ensure that line breaks come through correctly. And yes, I did have to break into browser-specfic code at times.

Surprising things can happen to space characters ‘twixt the HTTP stack and the paste buffer. Throw in newlines and tabs (On second thought: no, don’t throw in tabs; throw them out), and life gets very interesting indeed.

While the resulting release doesn’t quite fit the criteria for being WYSIWYG, I’d say it does at least satisfy YCAGWYWBIYTSYJMFYGWYN. Tab characters are converted to spaces, and there are often one or two spaces added at the ends of lines. I’m guessing that this will be close enough for most uses. For those cases where exactness is required, there’s still the toolbar command for view the original source as plain text. The popped-up text preserves the original whitespace, and a “copy” works just fine there. Putting this all together, it did seem to me that the Flash app could now be dropped, and so I’ve done so.

I’ve also added some tentative support for titles. Unfortunately, I can’t show an example in this post, because the WordPress Plugin doesn’t support the option yet; but you can see an example here. (I’d thought about adding this previously, then discarded it as creeping featurism, and then re-considered it when I realized that it might be of use for the visually disabled.)

And there are a lot of changes under the hood; I’ll write about these in separate posts.