Re: <code> element and scripting languages

I don't know how mailing list threads are handled, but since it was me who
started this, I guess I should put a sort of stepback statement.
After the answers from Gannon Dick about possible conflicts between my
proposal of use for @lang and existing language tags, I contacted ISO 639-3
Registrar authority in order to ask whether such "custom" subtags would be
compatible with current non-BCP47 standards.

Today I received an answer from Doug Ewell, IANA Co-Designated Expert for
BCP 47 and software developer. In his really kind and thorough answer, Mr
Ewell informed me that, differently from what I had in mind, language tag
is not suited at all to convey information about programming language. In
particular he cited me a paragraph from BCP 47 (RFC 5646, Section 2):
> "Language tags are used to help identify languages, whether spoken, written,
signed, or otherwise signaled, for the purpose of communication. This
includes constructed and artificial languages but excludes languages not
intended primarily for human communication, such as programming languages."
And about my comparison between programming languages use case and existing
extension subtags such as "language and/or locale-based behavior or
refinements to language tags" (RFC 6067 as registered by Unicode Consortium),
he correctly states that
> The 't' and 'u' extensions (RFCs 6497 and 6067) do not conflict with this
principle. Their purpose is to support the tagging of supplementary
localization
information which appears together with language identification.
Thus said, it is obvious that neither extension subtags, nor private use
subtags can be used for this purpose.

I close with a request. Marking code snippets with their <code> tag and an
attribute-based programming language distinction, could equally be useful
for some purposes, namely, search engine indexing and syntax highlight
(custom-made
or even native for some languages, now it doesn't matter). @class and
@data-* are used and (in the case of @class) loosely fit. But a new
@language attribute could fit better. It is suggested by the class value
proopsed in the spec (class="language-pascal" in the example) and it is
also known to authors, as everybody knows (it was incorrectly specified on
<script> tags). It's not an important issue, but I hope to see it realised
in a consistent manner someday.
Cheers
Andrea Rendine