Am .03.2015, 14:05 Uhr, schrieb Andrea Rendine
<[email protected]>:
Martin, IDK about plang but I guess Michael Pieters weren't serious when
suggesting that (was he?)
I was serious when I said it would be better than @language. On a second
thought, <code> isn't for programming languages only, so @plang isn't
ideal either. But I'm sure there can be something better still (@codelang,
@clang, …?).
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".
A non-canonical (and pretty useless) attribute occasionally seen in the
past does not convince me. I don't think such a curiosity prevents today's
authors from confusing @lang and @language. Again, what bothers me is that
both argument names literally say the same (it's just that one of them is
an abbreviation) and can be used on the same element at the same time and
are supposed to mean two different things. An example: There's nothing in
the following two lines that hints at which markup is more appropriate:
<code lang='de' language='html'><h1>Hallo Welt!</h1></code>
<code lang='html' language='de'><h1>Hallo Welt!</h1></code>
The problem is that @lang and @language don't express the different
concepts that they represent.
Also consider that
the spec uses class="language-python" as an example of programming
language markup.
There are no strong semantics implied in class="language-python". It
doesn't hurt when the next author uses class="lang-python" and another one
uses class="language-bavarian" to define a different font for a text
section in Bavarian dialect. Confusing @lang and @language would be
unfortunate though. It would lead to wrong 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)
Does use of additional parameters suggest that a new attribute providing
only an identifier for the code language would not be sufficient for
syntax highlighter markup? So a new attribute might not always be
sufficient to enable authors to switch syntax highlighters easily. (That's
not an argument against your proposal, Andrea, but it weakens an argument
I saw in favor of the proposal.)
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?
Not much. But what does that tell us?
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?
That's why I'd like to have input by UA makers whether they have interest
and use for that and how it should be designed best to be usable for them.
Martin
