Re: <code> element and scripting languages

Hi Alexandre. Nobody is real "late", as I don't think it will translate
into a real proposal, it was just an idea or something like that, inspired
by a couple of lines in the spec.
You say that @data- is not ideal and I totally agree, as data- is not
suited for a global approach. But the same can be said for @class. As you
see, as far as there are no syntax constraints, variants in the possible
values are just too wide. And even if it were "artificially" standardised
using suggestion tables or even in the spec itself, this would turn @class
from an almost-free text attribute to a partially enumerated one. And
what's more, class is never meant to be exposed to users or used by user
agents (apart from CSS application) and it has poor semantic value. One
thing is "writing classes with semantics in mind", another is "make class
convey semantics". About the point of Microformats, IDK how much it is used
(I totally prefer RDFa for extended semantics, and now there's also the
stuff about Microdata), but this means that language classes should share
room with "microformat classes" and "style-oriented classes" (one could
apply CSS to previously-defined classes, but if you look around you will
see that class indication is far from being efficient, and some scripts
interfere with classes too). And in a user agent-scenario, the proper value
for a language should be fetched among all these values in order to be
used, e.g. by user agents, for indexing content as language example.

@type is a somewhat better choice, but it's associated with the concept of
MIME types and data parsing. In our case, nobody cares if the language
being shown is, e.g. "text/*" or "application/*", as it is only to be
exposed as text. And it would present issues regarding language with no
official MIME types, or with coexistence of official and unofficial types
(e.g. what would you use for JS? Official application/ecmascript or
application/javascript? Widespread variant text/javascript)? Language is
more immediate and it is usually associated with a language "name", which
would be less ambiguous in my opinion.

About your note for localised programming language, this is definitely
something I didn't know. However, this wouldn't prevent the use of @lang,
as e.g something like "French-localised 4D with commentary in US English"
could be indicated with lang="en-US-x-4D-fr" (which is valid (according to
BCP-47, Gannon, I know...)), with a simple note about using primary
language subtag for comments and (occasionally) private subtag after the
language name for local variants.