Re: <code> element and scripting languages

> 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.
So would I, indeed.

> Not much. But what does that tell us?
It tells us that we need consistency. And @class cannot give it. It is not
meant as an enumerated attribute, and as such it is used quite freely.

>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?
No. Gorbatchev' syntax highlighter parameters offer a series of features
which are pretty much stylistical (
http://alexgorbatchev.com/SyntaxHighlighter/manual/configuration/), such as
HTML/script mixture (but nested <code> would do it better), line marking
(it'd be better to use proper HTML inline marking), link detection (if a
link is to be meant as a link, it'd be better to use a link); nothing that
cannot be solved with CSS or additional markup (more complex, but also more
semantically relevant).

> A non-canonical (and pretty useless) attribute occasionally seen in the
past does not convince me
> There are no strong semantics implied in class="language-python".
Those arguments are not towards semantics, rather in the direction of
common use. Actually, @codelang is quite neat instead.

2015-03-30 15:06 GMT+02:00 Martin Janecke <w3.org@prlbr.com>:

> 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
>
>