CSS highlighting on Stack Overflow isn't working.

[GoogleCodeExporter]

On Stack Overflow (which as you know, uses Prettify) the highlighting for CSS 
code isn't working.

Here are the relevant Meta discussions:
http://meta.stackoverflow.com/questions/121816/whats-happening-to-syntax-highlig
hting-for-css-questions
http://meta.stackoverflow.com/questions/99725/html-markup-blocks-dont-highlight-
as-html-in-css-questions-automatically

At the moment, the "prettify style" for the "css" tag is set to "lang-default".

Here's an example of it not working: 
http://stackoverflow.com/questions/5186712/stretch-horizontal-ul-to-fit-width-of
-div/5186832#5186832

The CSS in my answer is:

#horizontal-style {
    display: table;
    width: 100%;
    /*table-layout: fixed;*/
}
#horizontal-style li {
    display: table-cell;
}
#horizontal-style a {
    display: block;
    border: 1px solid red;
    text-align: center;
    margin: 0 5px;
    background: #999
}

Is there any way that Prettify could be improved to detect that as being CSS?

Alternatively, do you have any ideas on how Stack Overflow could go about 
fixing this on their end?

Original issue reported on code.google.com by thirty...@hotmail.com on 24 Feb 2012 at 12:38

[GoogleCodeExporter]

I added

   <!-- language: lang-css -->

to that code section as explained at 
http://stackoverflow.com/editing-help#syntax-highlighting and it seems to work.

Original comment by mikesamuel@gmail.com on 30 Mar 2012 at 2:44

• Changed state: Fixed

[GoogleCodeExporter]

I think the main issue here is that Prettify can't identify CSS without the 
explicit language hint. Is this a limitation of the lang-default style?

Original comment by boltcl...@gmail.com on 30 Mar 2012 at 3:40

[GoogleCodeExporter]

It is a limitation of the language detection.

Right now, I do the following

1. If there's a language hint, and there is a loaded language handler for that 
hint, use it.
2. Otherwise, if the first non-whitespace character is a '<' assume a handler 
that works well for HTML & XML.
3. Otherwise, assume a handler that works well for C-style, Bash-style, and 
Python style languages.

The last is the one which triggers and it is very naive.  I am of the opinion 
that default algorithms should be as correct as possible, but not in ways that 
make them hard to explain or debug.  Also, to do proper language detection 
requires either

- bayesian methods over token and keyword frequencies which are hard to 
diagnose, increase code size, and produce low-confidence results for small code 
snippets
- or fallback parsing which increases runtime and doesn't work on malformed 
snippets like 'f( WHAT GOES HERE??? )'

I believe SO tried to address the shortcomings of this algo by looking at the 
set of tags on the question but I don't know what they ultimately did there.

Original comment by mikesamuel@gmail.com on 30 Mar 2012 at 7:08