I would not perform htmlspecialchars on the client side. I would leave it as is, and do it on the server side. Always assume the client is insecure/unsafe.
Strictly speaking, anything that's going to be sent, no matter how indirectly, to the bbc parser 'should' go through preparsecode, and if memory serves, preparsecode does not perform htmlspecialchars anyway, because I seem to recall it's always done ahead of time by other processes.
It's complicated because there are other side matters to attend to with it. preparsecode actually does an insane amount of stuff, IIRC the list in no particular order is:
* convert newlines to br tags (not entirely sure why it does this, I've never fully understood this logic but I'm assuming it's for the benefit of code tags so that you don't try second guessing p tags, and it means if you want a double blank line, you get one)
* validates that anyone using the html bbcode is an admin (or remove the tag otherwise)
* breaks the content of nobbc bbcode so that it won't be parsed (physically convert the brackets to their numeric equivalent)
* attempt to fix table tag hierarchies through regular expressions (table must contain tr, tr must contain td, td must be inside tr, tr must be inside table, list must contain li, li must be inside list)
* convert double space to nbsp+space so they're actually displayed as such
* break instances of [] and [' so that they're not parsed as potential bbcode for speed (e.g. inside people posting code outside of code tags)
* convert /me to the me bbcode
* convert specific colour bbcodes to the generic case (e.g. replace red, blue, etc, bbcode with color=red, color=blue)
* invoke the tag scheme checker to go through img, url and similar tags looking for valid http/s entries and forcing them to have the right scheme
* if images are posted and there is a maximum image size, validate the image's size and rewrite the img bbcode if necessary to include new sizes
It is pretty insane when you think about it! But that's what's required to ensure that any arbitrary posting is safe to be displayed later. (More, in fact, could be done, because it could step through the tags at save time and validate that they are properly nested and so on, and take that burden off parse-bbc)
Long story short, it depends on what you're looking to allow in the thought system. If it's the small list of inline codes, you don't need to invoke the entire preparser, but it will need a subset of the loop at the end of the routine where it splits the post into sections by code tags, most importantly to catch the fixTags call (to sanitise links and/or images posted, though images should probably be rewritten to links anyway!)
You don't need to have it also do the regexps that handle fixing table/list nesting because they're not going to be parsed anyway, so no need to alter them (and I'd suggest not altering the thought for that purpose)
Perhaps there should be a parameter to preparsecode, for inline parsing requirements, where if false, only do what's necessary for inline bbc requirements.
which means that if they have BBC, they end up showing HTML tags in the code. Hmm...
This is a problem that has affected many, many people in figuring this stuff out. The HTML to BBC converter is not rugged, but if you're only feeding it the inline tags, it's probably enough.
