Powerful, XHTML-compliant, server-side code highlighting for pretty much all languages
As long as they aren't wrapped in
<pre>-tags with a
lang=-attribute nothing is going to happen - your markup will stay untouched. Highlight Source Pro only hooks in for those
<pre>-tags having a
The line-numbering is the one problem here, because - currently - it requires to break with the XHTML-Standard. Because the
<ol> is always and guaranteed inside a
<div> with the
.geshi-class there is no need for the
class-attribute on the list element. Also due to the fact that a CSS-classname is not allowed to start with a number, this solution is valid XHTML for downgrading and can never interfere with existing CSS-rules.
Yep. The basic idea is, once again, backwards compatibility. If you consider your code-blocks being important you'll most likely want to add a heading instead of just a line, on the other hand you can simply use the title-feature to show which file is being talked about. Since the title-string will be placed inside a
<div> you'll be fine as long as there's no line-break (and your markup is valid)
There's two ways of handling code-listing in your original post source. You can either use the HTML-input and hardcode PHP, C or whatever you think about, statements in there, Highlight Source Pro will handle those listings without any problems (in fact, it's the safer version to use for Highlighting as all characters are present in their original form).
On the other hand this will get problematic if - for any reason - you stop using Highlight Source Pro, because WordPress (and every other serious software) will strip lots of those listings for security and compatibility reasons. If you want to be sure that your listings don't break when moving to another platform you should consider using htmlentities() on your listings, or writing them with the Visual Editor in the first place, so when falling back everything will be displayed as you want.
In this case you'll have to use the
enc__-prefix to tell Highlight Source Pro to apply
html_entity_decode() before the actual syntax-highlighting. While this might be the more default case it's still the one requiring the alteration with the prefix, for compatibility reasons. If encoded scripts would be marked with the original language-signature and the source would later on be used in another GeSHi-environment things would get very, very complicated and confusing.