I would like to recommend to let the author decide whether or not a piece of code should be highlighted (i.e. not make it configurable in the User Settings).

I think you raise a good point but I think that you need to consider this idea more carefully from more angles.

For example, I don't care what you or any other author decides, I don't ever want to see rainbow code (at PerlMonks when I'm logged in). So it needs to be a choice of the viewing user. You make a good point about there being value in it also being a choice of the author.

However, I don't care what burden you hope to put upon authors about declaring what type of code they have posted nor hoping they will check whether the syntax highlighting is doing a good job on their code; I won't be shouldering that burden for chunks of code that I post and I don't think it is reasonable to expect all authors to (and trying to do that would be doomed to failure anyway, IMHO).

But the more I consider this idea, the more I think it is doomed. Perl syntax highlighting imperfect (always, at this point) and so it is a reasonable option to select to follow for your own code. However, trying to get some other person to bend to the idiosyncracies of the Perl code highlighter that somebody else chose will always just be aggrevating, even unacceptable to some people. This will just be another source of strife.

So the choice of the highlighter needs to be in the control of the viewing user and the viewer needs to be able to disable it when it fails.

Perl syntax highlighting is imperfect (always, at this point)

I actually ... umm ... believe that "syntax highlighting" appears just as mostly keyword highlighting. There seem to be some other code sites around (haven't noted any URLs, sorry) that show bits of code and hey, it looks like code 'cos every if and while is in bright turquoise on dark grey.

Now for serious syntax highlighting like one might like in an editor for actually working on code, I'd agree. I get constantly infuriated with Emacs because it's not making the code 'look right' - and if that's the case then sometimes it's maybe preferable to go with kyle and "don't use it".

But I do often find just the basic keyword signposts useful for quick scans of the code. In which case a very simplistic mapping could be selected at either entry time or rendering time.

This signature will be ready by Christmas

I like that; in addition to letting the user decide whether they get any highlighting/JS. It sort of has to be author controlled anyway because the author would need to choose what the code snippet syntax was -- Perl, SQL, XHTML, etc.

Style attributes -- like <c style="whatever">snippet</c> -- probably shouldn't be supported because it would add a bunch of sanitization parsing if it's literal HTML style and plain old parsing/logic if it's not real HTML. Classes would be easy and innocuous. <c class="xhtml">snippet</c>. Or, in the spirit of <c/> pseudo-tags <perl>say "hello"</perl>. I actually used that idiom in a server side PPI driven highlighter. Using it for a year or so I'm kind of luke warm on that approach.

I really like the idea of Chili after thinking more about it. I believe there are a couple of syntax files for it to do Perl floating around but it would be great if the community could own the definitive version. It would certainly be vetted better just by being used here than it would be as any sort of independent release.

I doubt it'll happen and I won't cry if it doesn't but it would be fun. I volunteer to work on it if it gets some steam and needs an extra hand.