Re: [whatwg] Using @type on to specify the computer language
Mathias, mind that while libraries support using the @class attribute, there's no standard between them about whether to use a prefix before the language or if a prefix is necessary at all. Besides, @class has no semantic value. It's true that the spec suggests using "semantic" class names (instead of layout-inspired, I mean), but there's no real meaning for that. 2015-05-09 14:48 GMT+02:00 Mathias Bynens : > There is a de facto standard here that is already supported by most > syntax highlighting libraries, based on this part of the spec: > https://html.spec.whatwg.org/multipage/semantics.html#the-code-element > > “There is no formal way to indicate the language of computer code > being marked up. Authors who wish to mark code elements with the > language used, e.g. so that syntax highlighting scripts can use the > right rules, can use the class attribute, e.g. by adding a class > prefixed with "language-" to the element.” > > I’d prefer following that pattern over inventing a new one.
Re: [whatwg] Using @type on to specify the computer language
There is a de facto standard here that is already supported by most syntax highlighting libraries, based on this part of the spec: https://html.spec.whatwg.org/multipage/semantics.html#the-code-element “There is no formal way to indicate the language of computer code being marked up. Authors who wish to mark code elements with the language used, e.g. so that syntax highlighting scripts can use the right rules, can use the class attribute, e.g. by adding a class prefixed with "language-" to the element.” I’d prefer following that pattern over inventing a new one.
Re: [whatwg] Using @type on to specify the computer language
Long ago I proposed an attribute for code language because I was unhappy with all the class="language-whatever" thing. I proposed @lang because I thought there could be an issue with speech synthesis and languages, but it was effectively pointed out that such attribute does not fit this case. +1 for @type, it is widely consistent to use that for MIME types. But I guess that it will bring nowhere (as usual) unless vendors show any interest for this issue.
