86

In this question tagged and and a non language related user-input tag the following really simple block of HTML,

<input id="foo" type="text">
<input id="bar" type="text">

got detected as as seen by the language class added to the <pre> tag:

<pre class="default s-code-block hljs lua">

When detected as different language the HTML tags are not treated as such and get wrapped in a different span class with different theme coloring

Is this 100% a bug in highlight.js which has its own auto-detection or are the question tags not used to help qualify the language detection?

16
  • 41
    While not using the tag to help out the autodetection is a problem, I'd really like to see justification for why text that isn't even grammatically valid Lua gets counted as that language. Commented Sep 28, 2020 at 1:58
  • @CertainPerformance: Did something change in the highlighting? I don't think I remember the Iterator snippet having italics when I wrote my answer, but I could be misremembering. Commented Sep 28, 2020 at 8:47
  • 1
    Here's another example with matlab and python tags, where code blocks for each were highlighted as yaml (before I edited in specific highlighting)
    – Wolfie
    Commented Sep 28, 2020 at 10:37
  • 3
    Another example, tagged as python, auto-detected as Lua. Commented Sep 28, 2020 at 10:41
  • 6
    @NicolBolas The heuristic doesn’t check for grammatical validity and never did, because this wouldn’t be feasible efficiently (and would yield false negatives for invalid code anyway). But there’s nothing obvious in the Lua language highlighter definition which would cause the heuristic to classify these snippets as Lua. And when I check it with a local build, it does not classify these snippets as Lua (but still incorrectly). Commented Sep 28, 2020 at 10:46
  • 1
    (That said, Lua is ranked higher than the correct language on these snippets since the lexer matches more individual Lua lexemes; this is pretty much by design, since the highlightjs lexers don’t match operators, though it could potentially be improved by adding illegal symbols to the language definition.) Commented Sep 28, 2020 at 11:05
  • @JörgWMittag It initially had italics (detected as markdown), then I added the language tags after realizing the highlighting was off (before you posted your answer), then I rolled it back after seeing this question so I could use it as an example Commented Sep 28, 2020 at 13:40
  • 4
  • 47
    highlight.js has been a complete failure so far in both language detection and colouring of manually tagged languages - not only all languages look the same now, they also look nothing like what I see in their respective IDEs (which was not the case before), and in many cases, valid languages constructs are highlighted incorrectly as comments, or left not highlighted. Actively maintained or not, prettify was delivering a that much better result.
    – GSerg
    Commented Sep 28, 2020 at 16:02
  • 12
    I think this question would benefit from a better title — one which clearly conveys there are several problems with highlight.js which need to be addressed. The current title makes it look like an innocent "How does it work?" question and that may be the reason why it has just 1k views and still no answers after a couple days in HMP.
    – walen
    Commented Sep 30, 2020 at 8:06
  • 14
    I cannot really understand HOW the hell can you switch to a different highlighting engine without even making sure that the end result remains consistent. What's so hard about that? You don't even need to know anything about front end web development to understand this. Colors didn't even go from A to B, they went straight to Z, the current highlighting is bonkers: awful and inconsistent colors all over, and sometimes even wrong colors (as much as I can try to imagine the logic behind them). I use SO daily, this change was like going to sleep and waking up in the middle of the ocean. Commented Sep 30, 2020 at 13:45
  • 3
    @GSerg To be fair to highlight.js, in addition to the issue of SE not providing correct language hints to highlight.js, SE decided to change the syntax highlighting color palette at the same time they changed to highlight.js. In the color palette change, SE decided to map 35 different parts of code which highlight.js identifies to 11 named colors (2 are the identical color, so 10 colors total). As a result, we're actually seeing a lot less differentiation than highlight.js provides. Basically, while highlight.js does have some issues, a lot of what we're seeing is on SE, not highlight.js.
    – Makyen Mod
    Commented Oct 2, 2020 at 5:12
  • 8
    To be fair to SE, we should keep in mind that choosing colors for this type of thing is hard. Personally, I would have preferred that if SE was going to go with a different color palette than they were previously using, that SE make that a separate change. In other words, switch to highlight.js. Get it working to a level comparable with the previous implementation, using the same color palette. Then, once the highlight.js implementation is known to be functional, change the color palette. Doing both changes at the same time makes it more difficult to determine the root cause for each issue.
    – Makyen Mod
    Commented Oct 2, 2020 at 5:14
  • 2
    [Highlight.js maintainer here] @GSerg I can't fully speak to auto-detection. Many (not all) of the auto-detect problems on SE are SE related issues, not ours. Regarding manually specifying the language if you have specific examples of issues with specific languages, bug reports would help. If you're seeing comments highlighted incorrectly that very much sounds like a tagging (wrong language) or auto-detection issue, not a grammar issue. We typically get the comments right at least. :) Many reported grammar issues have been fixed since SE adopted the library. Commented Feb 15, 2021 at 3:29
  • 1
    If there is anyone who is an expert in prettify and it's engine/grammars that could directly compare them to what we're doing that would be super interesting and maybe helpful. That said, there are probably things we're simply going to do differently because of our own conventions, etc. But I'd love to see a few worse-case side by side comparisons paired with an understanding of how prettify worked (which I do not have). And maybe we'd learn something useful. Commented Feb 15, 2021 at 3:34

2 Answers 2

24

There are 2 main parts to this:

  • When highlight.js is used to detect a language, if it is given no constraints on languages to choose from, it will choose the language that results in the most distinct highlighting. If the site has a large number of available languages - like here on Stack Exchange - then the resulting chosen language is frequently inaccurate. This is a deficiency on highlight.js's side.
  • When Stack Exchange asks highlight.js to highlight code blocks in a question, it will either require all code blocks to be highlighted with the same language (if the question is tagged with exactly one tag associated with a language), or (in all other cases) it will ask highlight.js to detect the language automatically, without any language constraints. As a result, the resulting highlighting is frequently off. This is a deficiency on Stack Exchange's side, and is easily fixable.

How highlight.js does it: When it needs to choose a language to use given code text, it tries highlighting with all languages it can, and the one with the highest "relevance" wins:

Highlight.js tries to automatically detect the language of a code fragment. The heuristics is essentially simple: it tries to highlight a fragment with all the language definitions and the one that yields most specific modes and keywords wins. The job of a language definition is to help this heuristics by hinting relative relevance (or irrelevance) of modes.

So, if some language happens to share a similar structure and/or keywords with another language, and if the highlighter is not given any hints as to which language is preferable, it may well often get those mixed up.

How Stack Exchange does it: Some of this is described in the meta FAQ. Other details in a Meta post I made on this subject.

  • Some tags are associated with highlight languages. These associations can be seen at the bottom of the tag wiki page, eg javascript is associated with lang-js:

    Code Language (used for syntax highlighting): lang-js

  • If a question has exactly one tag with an associated highlight language, all code blocks in the post get highlighted with that language.

  • If there are 2+ tags associated with a highlight language, all code blocks in the post are highlighted by having highlight-js guess at the most appropriate language between all available languages (not just the languages associated with question tags, but with all possible languages SE has loaded), which doesn't work well.

  • If none of the tags on a question are associated with a highlight language, no automatic highlighting will occur (not even guessing).

In the case of the question being asked about:

  • Neither tag on the question has a language associated with it, so auto-detection was used. You might think "We should associate the html tag with the xml highlight language, or the jquery tag with the javascript highlight language", but given the current system, adding additional default languages to tags increases the chance of default-language collisions on questions, and such collisions result in neither language being passed to highlight.js.
  • Lua may have been chosen because both input and type are "built-in" words in Lua, so the highlighter found Lua to have the highest relevance of all languages it tried.

The fix

Stack Exchange can significantly improve highlighting accuracy by passing all related languages to highlight.js when a code block needs to be highlighted. For example, a question tagged with javascript and css should call highlight.js with ['javascript', 'css'] as language hints, rather than with no hint at all due to both tags being associated with a separate language. This can easily be achieved using highlight.js's current API. This is described at length in a post on Meta SE.

7
  • 1
    +1. All great points. But the code-fence language hints are so easy to add and be explicit. It's a handful of chars. No more need for that <!-- language: lang-foo -->. Commented Sep 30, 2020 at 16:36
  • 12
    They're easy to add for those who know about them, but a very large proportion of askers probably don't and never will. We still get hundreds of questions each day where the OP hasn't made even any attempt to format their code into code blocks. Getting language auto-detection to work out-of-the-box in combination with a plain code block would be better. Commented Sep 30, 2020 at 16:39
  • 1
    Now having read your Q on Meta.SE, I think I understand better. Especially for cases with >1 language in the post, it can guess independently and better. Very neat. Commented Sep 30, 2020 at 16:42
  • 1
    This is a great answer to "What can we expect from syntax highlighting and how does autodection work?" without being a rant. +1
    – Bergi
    Commented Sep 30, 2020 at 20:35
  • Hope this gets some attention paid to it by dev team. Somewhat surprised a CM or dev team member hasn't added any color to the issue
    – charlietfl
    Commented Oct 3, 2020 at 21:31
  • 1
    This is such a simple fix that it's obvious that it will never be implemented.
    – Ian Kemp
    Commented Oct 28, 2020 at 16:04
  • I wonder if what we actually need is a server side syntax highlighter. Yes, it would require SE to re-render when they update the library, but it's better than the current state of affairs.
    – Braiam
    Commented Jul 21, 2022 at 11:58
8

Speaking as a colorblind person:

I expect that we will take readable black text and colorize it into unreadable colorized text. Without an option to make it readable.

7
  • 9
    SO should have a special preference configuration optimized for the colorblind.
    – bad_coder
    Commented Sep 30, 2020 at 16:06
  • That is called a userscript @bad_coder
    – Luuklag
    Commented Sep 30, 2020 at 18:52
  • @Luuklag what's the percentage of folks that don't use userscripts?
    – bad_coder
    Commented Sep 30, 2020 at 18:59
  • @bad_coder Whatever it is, it's too high :D
    – Scratte
    Commented Sep 30, 2020 at 19:00
  • @bad_coder what's the percentage of users suffering from colorblindness?
    – Luuklag
    Commented Sep 30, 2020 at 19:24
  • 1
    @Luuklag Userscripts may not be allowed for all people. Imagine a person browsing SO from their working machine, with browser settings controlled by their company. They can't easily add any userscript or plugins to their browser (or it's simply forbidden). So it's the job of SE to implement this option IMHO.
    – Lino
    Commented Sep 30, 2020 at 20:21
  • @Lino, I have the same controlled computer. You'd be amazed at what's possible using the debugging tools from within the browser.
    – Luuklag
    Commented Sep 30, 2020 at 20:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .