Re: <code> element and scripting languages

Am .03.2015, 14:05 Uhr, schrieb Andrea Rendine  
<master.skywalker.88@gmail.com>:

> 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'>&lt;h1&gt;Hallo Welt!&lt;/h1&gt;</code>
<code lang='html' language='de'>&lt;h1&gt;Hallo Welt!&lt;/h1&gt;</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

Received on Monday, 30 March 2015 13:06:53 UTC