This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 24942 - lang=x-<language acronym> (private use subtags) for code language, maybe with preceding code for language used in comments. E.g. <code lang="en-US-x-js">, code fragment in javascript with comments and [...]
Summary: lang=x-<language acronym> (private use subtags) for code language, maybe with...
Status: RESOLVED WONTFIX
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-03-05 18:48 UTC by contributor
Modified: 2014-03-19 23:16 UTC (History)
3 users (show)

See Also:


Attachments

Description contributor 2014-03-05 18:48:36 UTC
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html
Multipage: http://www.whatwg.org/C#the-code-element
Complete: http://www.whatwg.org/c#the-code-element
Referrer: http://www.whatwg.org/specs/web-apps/current-work/multipage/index.html

Comment:
lang=x-<language acronym> (private use subtags) for code language, maybe with
preceding code for language used in comments. E.g. <code lang="en-US-x-js">,
code fragment in javascript with comments and custom var names in english used
in the USA. easy to select and semantically correct (actually program language
is different from native human language)

Posted from: 84.220.43.211
User agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.146 Safari/537.36
Comment 1 Ian 'Hixie' Hickson 2014-03-05 21:01:59 UTC
That's an interesting idea, but if we want to do this then the way to do it would be to update the language code specs, not the HTML spec.
Comment 2 Andrea Rendine 2014-03-05 21:51:26 UTC
Is it needed? The WHATWG spec already uses something similar (<html lang="en-us-x-hixie"). Private use subtags are free and in fact both lang="x-js" and lang="en-us-x-js" are valid. The only requirements are that they consist of no more than 8 letters and/or digits. I only propose that it could be a suggestion in the spec, along with class=language-[lang].
Comment 3 Ian 'Hixie' Hickson 2014-03-06 22:50:15 UTC
Well anyone can invent random proprietary tags, sure. But I presume the request was for something that could interoperate between different libraries and authors.
Comment 4 Andrea Rendine 2014-03-07 00:34:33 UTC
It is true indeed. According to the text of BCP 47 (I hope that this version is correct: http://tools.ietf.org/html/bcp47#section-2.2.7), private use subtags come "by private agreement only" and the BCP 47 spec itself doesn't have to contain all the specific variants. It only defines main language and subtags, but it explicitly excludes those introduced by the x-.
Now, as this concept is particularly useful for the cases derived by the HTML <code>, <samp>, <kbd> and maybe <var> tags, the HTML spec could produce a list of abbreviations for known code languages that can possibly appear in a webpage describing said language, as content of the "private agreement" then followed by authors.
Actually it would be perfectly natural to use acronym and terms commonly associated with specific code language. The issues only come from those language whose name is not conforming to the lang tag spec (i.e. up to 8 characters in the classes of ASCII letters and decimal digits), such as Javascript or C++. By defining conventions for these languages (such as x-js for Javascript or x-cpp for C++), all the work would be done. It is a matter of private agreement and you can define a private agreement extended to HTML authors.
Comment 5 Ian 'Hixie' Hickson 2014-03-07 22:56:48 UTC
If it's in a standard it's not "private" agreement. If we want to put it in a standard, and I agree that it makes sense to do so, then the standard it should go in is the language tag standard, not HTML.