Re: <code> element and scripting languages

Martin, IDK about plang but I guess Michael Pieters weren't serious when
suggesting that (was he?)
However, language is well-known to authors as I said before. There was a
non-canonical (and pretty useless) habit of specifying @language on
<script> elements, with "javascript" +  the intended version, in order to
hide higher version JS scripts to legacy user agents. I.e.
<script type="text/javascript" language="JavaScript1.3"> would have masked
this script to UAs whose compatibility wasn't above JS 1.2.
So I guess that nobody would use @language for "en-US". Also consider that
the spec uses class="language-python" as an example of programming language
markup.

About why the way things are now is not good (in my opinion?) Look:
Prism.js => uses class="language-****" as per spec suggestion
SyntaxHighlighter 3.0 (by Alex Gorbatchev) => class="brush: js" (and I'll
spare you the other parameters in the example for your sanity) (also, it
applies to <pre> but not to <code> which is pointless on a strictly
semantical POV)
SyntaxHighlighter Evolved (WP plugin, so completely different approach, but
still worth mentioning) => "wrap your code in [language], such as
[php]code" (as per documentation). Outputs a series of
<code class="htmlscript plain"> elements (its use of <code> is impressively
wrong...)
highlightjs.org => class="html"
Do you notice any consistency? I'm not speaking about authors changing
highlighter, though it'd be worth considering. I also talk about semantic
value. A feature that UAs can look at and know, consistently and
interoperably, what kind of script we are talking about?