317

Update 2020-09-24

This is now live network-wide.

Update

This is now live on Meta Stack Exchange and Meta Stack Overflow. Any bugs and feedback can be posted here as an answer.

I’m Ben and I’m a dev on the Teams team here at Stack Overflow - we're the team focused on building the private Teams experience on SO. I’ve recently been working on our post editing experience and I’d like to show off some preliminary work that’s coming to the network soon.

TL;DR

We’re switching our code block highlighting library from Google Prettify to highlight.js. All your favorite languages are still supported and you won’t need to change how you write posts at all. The only major change is how we render highlighted code blocks. In addition, we’re taking this opportunity to introduce our new highlighting theme as well. We’re rolling this out in stages, starting with MSE/MSO with other sites to follow. (See the FAQ at the bottom of this post for dates)

Some history on Prettify / code block highlighting

I tried to do some digging on when we first adopted Prettify, but it seems that its history goes allll the way back to site’s earliest days. The earliest reference I could find was from back in ‘08. I asked around internally too and the best answers I could get were along the lines of:

¯\_(ツ)_/¯ - Everyone

Ask Atwood - Dean

and

If I had to guess, it was something along the lines of "there's not a lot of options, and this is used by Google so it's probably fine" - Kevin

Eventually the wonderful Tim Post pointed me to Stack Overflow Podcast #11, aired June 2008, where Jeff and Joel talk about how incredible it was for the time and how Google uses it themselves for syntax highlighting in Google Code (RIP). They also put out a call for alternatives, which I’d have to assume came up short.

Why the change?

Google Prettify hasn't been under active development for a while, and was officially discontinued by Google in April, as you all have let us know repeatedly. This means that no new language syntaxes1 are being supported and that existing language syntaxes aren’t getting updated to support all their new features. It’s time to move on to something that supports modern front-end workflows (such as providing an npm package, for starters) and continues to evolve to meet the needs of developers.

What’s changing about how I write posts?

Absolutely nothing :). There is absolutely no change to how posts are written. We still support all the Prettify language aliases you know and love, along with the new aliases from highlight.js. However, we are not adding support for any new languages at this time, instead choosing to keep the initial changeset simple and aiming for current feature parity instead. All the current markdown syntax is still supported, along with determining code highlighting from tags and site defaults.

So what is changing?

The “only” changes are visual. We are updating the client-side code block renderer that styles your code in posts (Questions, Answers, etc) and in the editor preview. Syntax autodetection when a language is not specified should be much better overall, along with syntax highlighting coverage in general. The biggest outward facing change for the typical user is going to be our new theme (see below for details).

Why highlight.js? Why not…

Why did we pick highlight.js over Prettify? Well, first off, you asked for it specifically. More convincingly, it’s open source, actively maintained, and overall just a solid product.

We’re extremely concerned about performance here at SO (both on the client and on the server), so we needed to ensure that this major change on our hottest page on the site didn’t negatively impact our users. There was some prior investigation into highlight.js's performance back in 2016, but I figured we should give it another shot.

In our internal performance benchmarks highlight.js scored better than Prettify consistently across all browsers (except macOS Safari 13.1, where it was actually a bit slower)2. It is a tad heavier than Prettify3, weighing in at an extra ~17kB (over the wire) after including all the languages we support across the network. This extra weight gain was acceptable to us as a tradeoff for what we were getting in return.

Why did we pick highlight.js over other contenders? Simply put, it was the best option that served our needs. We needed a library that we could easily control for use in the browser (deferred loading, theming specific elements), while also being simple to consume via a npm package, not needing specific build steps or a special babel plugin to pull in only the parts we need. Additionally, we could run it on the server (via Node.js) to unify our syntax highlighting in our Stacks documentation, giving us a single syntax highlighter across our products. Also a major plus was the ability to tokenize the highlighting result for use in our new editor (stay tuned!).

What are some potential drawbacks?

The most obvious not-quite-a-drawback is that language autodetection is different from Prettify. In general, it will be much more accurate, but will possibly end up with a different result that what Prettify would give us. This isn’t so much a bad thing, as it is just a thing that might take some getting used to if you’re a Prettify power user.

As mentioned earlier, the overall code bundle size is a bit bigger too. The vast majority of users wouldn’t even notice the change, which would only affect the first fetch since the browser will cache the file locally for subsequent hits anyways.

The last item is a bit of a personal preference. highlight.js tends to not highlight punctuation, which makes it a bit less colorful than other highlighters. This is considered a feature. Not a deal breaker by any means, but something I should mention regardless.

Designing the new theme

To offer some insight into how the new theme was designed, I reached out to the author, principal design systems designer Aaron Shekey.

Since we’re upgrading, we wanted to take this opportunity to design a Stack Overflow-flavored theme that takes advantage of newer tech like CSS variables that are aware of both light and dark modes. While we’ve improved it over the years, it’s highly likely that the current production theme simply used the stock colors provided by Prettify.

We’d need a theme that could work in both light and dark modes, was informed by Stack Overflow’s branded colors, and introduced a bit more contrast throughout.

Thankfully, we weren’t starting from scratch. When we built our Stacks documentation, we’d spent some time making our Jekyll theme display code snippets that got pretty close to accomplishing those goals. However, this was before dark mode was a thing, and we’d only built a single theme that assumed a fixed dark background. We’d have to extend this theme to light mode and revisit contrast along the way.

Using the Stacks documentation as a playground, we’ve now got themes in both light and dark modes that look like Stack Overflow and add or maintain contrast levels. We did our best to accomplish a contrast level of AAA, with a few variables dipping into AA. You can see the exact measurements commented in our colors constants file.

Here are a few screencaps of the new theme taken from my local development environment (click on the images to expand them). You can preview more languages (with an easy dark/light mode toggle) over at the Stacks docs.

Before

hljs before

After

hljs after

FAQ

  • Q: When is the rollout happening?

    A: We're planning to roll this out to meta.stackexchange and meta.stackoverflow on Thursday, September 10th. Rollout to the rest of the network is scheduled for September 24th, after the initial testing period. This is a soft rollout date, dependent on any bugs/feedback we get from the community during the testing period.

  • Q: What if I find a bug?

    A: Report bugs in an answer (one per answer) to this question. We'll keep this open for a couple/few weeks (until Friday, October 2nd) to address any immediate issues and then we'll update this post and ask you to post bugs as new questions after that time.

Footnotes

1 I checked, plural of syntax is syntaxes. Take that spell-checker!

2 Client-side benchmarks being what they are, we measured anywhere from ~49%-60% increase in the rate of ops/second depending on the machine and browser. Outliers being Safari 13.1 which had a ~29% decrease (favoring prettify) and Edge “legacy” scoring a ~279% increase over prettify!

3 Size comparisons were done comparing the prettify-full.en.js file taken from production vs the new highlight.pack.js bundle. Both were minified and served via a webpack-dev-server instance with the compress flag set (enabling gzip support). They were then included onto a regular html page with script tags and measured using the built-in browser dev tools. At the time of measurement, prettify landed at 23.3kB over the wire (meaning that the file was minified + gzipped) vs highlight.js at 40.7kB. This is a 17.4kB increase or about a ~74% increase in file size.

Improve this question
52
  • 61
    Good to see that the Teams devs are also bringing features to the public network!
    – Luuklag
    Commented Sep 8, 2020 at 18:40
  • 13
    I have some updating to do then, for example on this one: What is the default language for the syntax highlighter? ...
    – rene
    Commented Sep 8, 2020 at 18:56
  • 5
    @rene I have a (incomplete, I'm sure) list of posts that need updating after this goes live. I'll add this one to the list. Thanks for bringing it to my attention
    – Ben Kelly StaffMod
    Commented Sep 8, 2020 at 19:04
  • 7
    I hope the syntax highlighting FAQs (both here and on MSO) are part of that list as well.
    – Sonic the Anonymous Hedgehog
    Commented Sep 8, 2020 at 19:18
  • 2
    @SonictheMaskedWerehog Yup, they both are! Thanks for checking in though. Better safe than sorry with those posts since they're the "source of truth" for this feature.
    – Ben Kelly StaffMod
    Commented Sep 8, 2020 at 19:29
  • 13
    How badly does it choke when asked to highlight the omni-glot? (Yes, that's a single piece of code that's a different valid program in each of 294 languages.)
    – Mark
    Commented Sep 8, 2020 at 20:08
  • 10
    @Mark Honestly, not too bad. Speed was (visually, didn't actually benchmark it) comparable to my test page that had ~16 different languages on it. For the curious, the autohighlight detection marked that code snippet as bash.
    – Ben Kelly StaffMod
    Commented Sep 8, 2020 at 20:25
  • 15
    @SonictheMaskedWerehog why invest resources into something that isn't the core product?
    – Braiam
    Commented Sep 8, 2020 at 22:41
  • 2
    @Braiam I thought SO was their core product. Syntax highlighting is a core part of that.
    – Sonic the Anonymous Hedgehog
    Commented Sep 8, 2020 at 23:03
  • 31
    Q&A is the core product, @Sonic, not syntax highlighters. Syntax highlighting is just a small portion of that, and not in any way critical to the platform's success. It isn't something Stack Overflow needs ownership or control of. Just as you shouldn't develop your own JavaScript framework, you shouldn't develop all your own tools when there's something already out there that does the job well.
    – Cody Gray - on strike
    Commented Sep 9, 2020 at 0:07
  • 4
    Given that highlighting occurs client side, how about a feature that allows the user to specify the highlight.js template(s)? It would be very cool if code on SO looked the same as my IDE. Familiar (color) styling makes code easier to read.
    – Mike
    Commented Sep 9, 2020 at 1:02
  • 6
    Please, ask your questions as answers, as that gives Ben more room to respond individually!
    – Catija
    Commented Sep 9, 2020 at 6:19
  • 13
    Whatever you do, please don't change the line-height for code blocks
    – hkotsubo
    Commented Sep 9, 2020 at 12:53
  • 3
    Don't forget to update this page to mention highlight.js instead of Google Prettify.
    – Clonkex
    Commented Sep 17, 2020 at 1:43
  • 2
    @Clonkex Already good to go! You can see the update on the meta version of that page (happens automatically when turned on). Good looking out though
    – Ben Kelly StaffMod
    Commented Sep 17, 2020 at 19:21

38 Answers 38

Reset to default
1
2
3

Per advice at How does the highlight.js change affect Stack Overflow specifically?, I am copying my original bug report to this Q&A.

Because I first noticed this behavior coincidental with an update to Chrome, I originally suspected that some change in Chrome might be related, though not necessarily at fault. However, I just saw today the news about the change to the code renderer (i.e. this Q&A), and that change also happened at exactly the time that I first noticed this problem.

I now strongly suspect a problem with the highlight.js renderer itself.

The original bug report below:

Browser bug, or site bug?

Chrome just recently updated (to version 85.0.4183.121). After the update, code blocks found in deleted posts are rendered badly:

enter image description here

Interestingly, if you select the text, it looks okay:

enter image description here

Chromium-based Edge (version 85.0.564.51) still displays fine:

enter image description here

Of course, this may not be the case once Microsoft pulls into the Edge code whatever Chromium updated happened to cause this. Microsoft has updated Edge to version 85.0.564.63, and I still do not see this problem with that browser.

The above examples are C# code. I don't have ready access to deleted posts in other language tags, so I don't know whether this occurs for all code formatting or just C#. I'm guessing the former though.

Naturally, this seems most likely to be a browser bug. But it's not unheard of to find that some buggy HTML/CSS works fine in one version of a browser but not another. Hence this bug report.

Edit:

Additional information:

On further investigation on my part, I've discovered that this only occurs on some posts, not all. For example, I see the problem here, here (oddly, one code block is fine here, while the other is broken), here, and here, but not here.

Interestingly, even on the ones where it does happen, if I click the edit link (for example, so I can examine the markdown to see how it might be different), and then cancel the edit, the rendering is now correct, at least until I reload the page.

In every case I looked at, rendering is broken when the author used indentation to denote a code block (with the exception of the mixed-problem one noted above, which uses indentation for both blocks, but only the second renders wrong), while it's fine when the author used back-tick markup.

Also: if I use the touch-screen to change the scale, rendering is fixed immediately, on the first change in scale. However, if I use the menu to adjust the zoom factor, it remains broken until reaching 150% scaling, at which point it renders correctly.

Improve this answer
7
  • I can’t reproduce this on the same version of Chrome (macOS), and it’s almost certainly unrelated to highlight.js which, after all, does not touch the way code is displayed at all, so it won’t affect font rendering behaviour. I recommend posting a separate post as this is a serious bug — though probably unrelated to Stack Overflow.
    – Konrad Rudolph
    Commented Sep 30, 2020 at 10:40
  • 1
    @KonradRudolph: fact is, this new problem showed up the same day that Stack Overflow switched renderers. In any case, if you read the post above, you'll see that I did already post it as a bug, and it's gotten no response at all from the Stack Exchange team. Thanks for the downvote though.
    – Peter Duniho
    Commented Sep 30, 2020 at 16:14
  • Well it isn’t (it literally can’t be!) highlight.js related, so it doesn’t belong here. I missed the link to the original report; that’s the right way to report it.
    – Konrad Rudolph
    Commented Sep 30, 2020 at 17:05
  • @KonradRudolph: "Well it isn’t (it can’t be!) highlight.js related" -- unless you have debugged the problem and found out what is actually going on, you cannot possibly make that claim. And the idea that the component that has as its sole purpose to format the code as displayed in the browser "does not touch the way code is displayed" is just plain absurd. That's all it does.
    – Peter Duniho
    Commented Sep 30, 2020 at 17:08
  • I mean, sure. There’s a theoretical, absurdly low, probability that it causes that. But you seem to misunderstand what highlight.js does. It simply parses code and produces HTML <span> tags which, in turn, are styled using run-of-the-mill CSS (not even the font, it only sets colours). But even the CSS isn’t produced by highlight.js, it’s fully controlled by Stack Exchange. Highlight.js simply does not touch the graphical font rendering at all. It’s an engine that transforms strings into different strings. Graphics/rendering do not come into this.
    – Konrad Rudolph
    Commented Sep 30, 2020 at 17:14
  • @KonradRudolph: you are overlooking the fact that it really doesn't matter whether the bug is in highlight.js itself, or simply in the way that it's used. It's still a bug related to the change from Prettify to highlight.js. You claim incorrectly that "it can't be highlight.js related", which is patently false. It may be true that highlight.js itself cannot directly affect rendering, but to say that the problem can't possibly even be related to Stack Exchange's use of highlight.js is naïvely and prejudicially incorrect.
    – Peter Duniho
    Commented Sep 30, 2020 at 17:37
  • 1
    I'm curious to know who provides the training on how to respond to bug reports.
    – Rob Grant
    Commented Oct 2, 2020 at 11:03
3

More formatting issues with SQL

hightligh.js has proper support for PostgreSQL and PL/pgSQL.

Still, my code is messed up on a regular basis. Like in this example (I ended up with a workaround using dollar-quoting to keep it readable - which is also not recognized, although it should be):

Using pgsql as format specifier does not seem to have any effect. Seems like you removed that somehow? Falling back to sql is a poor substitute:

CREATE OR REPLACE FUNCTION return_result_table(_param1 integer[], _param2 text[])
  RETURNS text
  LANGUAGE plpgsql AS
$func$
DECLARE
   _table_name text := to_char(current_date, '"_XYZABC_"YYYY_MM_DD"_ZXCVBN"');
   _select     text := '(select * from some_other_function($1, $2))';  -- !
BEGIN
    EXECUTE format('CREATE TABLE some_schema.%I AS ', _table_name)
         || _select
    USING _param1, _param2;
   
    RETURN _table_name; 
END
$func$;

Can this be fixed?

This is particularly unfortunate as I am currently hard-coding the format specifier sql, which should later be pgsql once the issue is fixed. Or what's the best workaround for now?

Update: I settled with tagging pgsql for now. That seems to be ignored, currently. So formatting falls back to the language determined automatically (currently mostly sql for Postgres questions, I assume). Once pgsql is fixed, the format specifier will kick in correctly.

It will be fixed, eventually, or will it not?

In case you are unfamiliar with dollar-quoting in Postgres:

Improve this answer
8
  • 1
    I believe that is because SO is only using "SQL". They really should provide the individual SQL variants (such as PostgrSQL, etc) for best results. SQL is not intended to highlight ALL SQL variants well. If anything it's currently focused more on MySQL but long-term it should really be just ANSI SQL with people using the correct variant fo whatever server they are using.
    – Josh Goebel
    Commented Oct 7, 2020 at 15:25
  • Is $$ quoting a part of ANSI SQL?
    – Josh Goebel
    Commented Oct 7, 2020 at 15:31
  • @JoshGoebel: Dollar quoting is not part of the SQL standard. It's a (very convenient!) extension of the standard in Postgres.
    – Erwin Brandstetter
    Commented Oct 7, 2020 at 15:38
  • 1
    I have a PR to improve SQL to be less context dependent so will at least fix the fact that half the bottom of your snippet is detected as a string... Right now the ; in the middle is tripped it up because it reads that as the end of the statement.
    – Josh Goebel
    Commented Oct 7, 2020 at 17:21
  • 2
    I believe Josh maintains the highlight.js library. However SE would still need to update the version they are currently using then. This is a notourisly slow process.
    – Luuklag
    Commented Oct 12, 2020 at 12:44
  • 1
    @luuklag There is no reason it needs to be so slow for minor/patch releases. We'll see if it improves going forward. A minor version bump of Highlight.js should be relatively trivial. Even if they wanted to allow time to us to find any issues in a new minor release usually that happens within a few days or week... and we do have a large number of tests. So if stability was a concern a policy of "wait ~1.5 weeks after minor release, then upgrade" should be quite safe. We'll see how it goes. I just released 10.3.
    – Josh Goebel
    Commented Oct 17, 2020 at 18:04
  • @JoshGoebel I didn't imply there are reasons, from hearsay and exoerience it is known that staff takes a while to update these things.
    – Luuklag
    Commented Oct 17, 2020 at 21:30
  • Well perhaps I shouldn't have said "no reason"... lol... SO is also a pretty huge service, and I'd call code highlighting a "critical feature"... so I'd imagine to some degree a known set of bugs with an existing library is better than unknown bugs in a new release. So if I was guessing I'd say "system stability" might be a concern that weighs into some of these decisions... perhaps. Although again minor releases and patch releases should be "pretty safe". :)
    – Josh Goebel
    Commented Oct 17, 2020 at 21:33
3

Java highlighting difference

I don't know what the exact rules was, but in the old highlighting any word in the Java code starting with a capital letter was highlighted.

I found this a nice feature since class names should start with a capital letter, so class names would stand out from variable names in the code.

Of course there was an issue when people didn't follow Java conventions, but overall I found the code easier to read.

In the new highlighting there isn't any difference between capitalized or uncapitalize words, so class names and variables names all appear the same.

Improve this answer
1
  • I'd say this is intentional since there is no real difference (only a convention as you said).
    – Josh Goebel
    Commented Oct 7, 2020 at 15:15
3

Ruby numeric literals are not highlighted as expected

In Ruby, float, rational, and complex literals render like so:

3.5e4
2r
6i

The expected behaviour is for the entire literal to be highlighted. For comparison, here are the same float and complex literals with Python highlighting:

3.5e4
6j

(Python uses j instead of i for the imaginary unit and doesn't share Ruby's literal syntax for rationals.)

Is it possibly an upstream issue?

Improve this answer
6
  • 1
    Python has a j suffix for imaginary numbers which is indeed highlighted. Other suffixes are not highlighted, so the Python behavior is definitely correct and the one for Ruby needs to be fixed.
    – Sebastian Simon
    Commented Sep 28, 2020 at 10:19
  • Ruby's grammar is not aware of these numeric variants, but it could be. Would be happy if someone created a PR. :-)
    – Josh Goebel
    Commented Oct 7, 2020 at 15:16
  • @JoshGoebel I had a look at the grammar (right before you commented, strangely enough). I think maybe I could put something together...
    – Dingus
    Commented Oct 8, 2020 at 12:07
  • @Dingus PR is welcome. :) Lots of other languages to see samples from.
    – Josh Goebel
    Commented Oct 8, 2020 at 12:14
  • Created an issue to track this. github.com/highlightjs/highlight.js/issues/2766
    – Josh Goebel
    Commented Oct 17, 2020 at 17:58
  • 1
    Merged and will be released when 10.4 comes out.
    – Josh Goebel
    Commented Oct 28, 2020 at 2:52
3

Display bug in an answer to a post with - which should get it Python-like coloring. A string is colored in two different ways:

Two different string colors

Improve this answer
1
  • 3
    Well the the snippet isn’t valid Python code and the highlighter assumes it is, and hence highlights it incorrectly (the highlighter has special logic to colour class names, and gets thrown off by the class keyword).
    – Konrad Rudolph
    Commented Sep 29, 2020 at 7:51
2

C code in a question tagged and is misdetected as .

What?!

typedef float pnt[3];

void count(pnt const * pnts, const int n, unsigned cnt[8]) {
 
  for(int i=0; i<8; ++i)
    cnt[i] = 0;

  for(int i=0; i<n; ++i)
    if(pnts[i][0]>=0.0f && pnts[i][1]>=0.0f && pnts[i][2]>=0.0f ) ++cnt[7]; else
    if(pnts[i][0]>=0.0f && pnts[i][1]>=0.0f && pnts[i][2]< 0.0f ) ++cnt[3]; else
    if(pnts[i][0]>=0.0f && pnts[i][1]< 0.0f && pnts[i][2]>=0.0f ) ++cnt[5]; else
    if(pnts[i][0]>=0.0f && pnts[i][1]< 0.0f && pnts[i][2]< 0.0f ) ++cnt[1]; else
    if(pnts[i][0]< 0.0f && pnts[i][1]>=0.0f && pnts[i][2]>=0.0f ) ++cnt[6]; else
    if(pnts[i][0]< 0.0f && pnts[i][1]>=0.0f && pnts[i][2]< 0.0f ) ++cnt[2]; else
    if(pnts[i][0]< 0.0f && pnts[i][1]< 0.0f && pnts[i][2]>=0.0f ) ++cnt[4]; else
    ++cnt[0];
}

It renders as

Enter image description here

Improve this answer
8
  • 2
    Both the C and C++ tag have a highlighter set (lang-c and lang-cpp). When two tags have a highlighter it falls back to lang-default. Add an explicit language hint to each code block.
    – rene
    Commented Oct 8, 2020 at 10:09
  • 1
    @rene Interesting, I didn’t know they would cancel out, that’s definitely not great.
    – Konrad Rudolph
    Commented Oct 8, 2020 at 10:35
  • I didn't know either. I needed Martijn to explain how it worked, See my revisions here: meta.stackoverflow.com/a/401174/578411
    – rene
    Commented Oct 8, 2020 at 10:42
  • 3
    There is also a feature request to supply all the tag-associated languages as hints to highlight.js instead of a fully 'blind' autodetection: meta.stackexchange.com/questions/354793/…
    – Marijn
    Commented Oct 8, 2020 at 10:56
  • > "When two tags have a highlighter it falls back to lang-default" This definitely sounds like poor behavior on SE part. I'll jump into that thread next but both tags can easily be input to the auto-detecting algorithm, ie SE could easily tell us "I KNOW this either is C or C++ code". And with a small amount of extra effort you could "weight" the highlighter such that "I'm confident, but not entirely sure this is C or C++ code".
    – Josh Goebel
    Commented Oct 17, 2020 at 18:13
  • That said this specific case is definitely an issue with our XML grammar being too greedy. It seems all those < as HTML and starts crediting everything it sees as an HTML attribute... which makes no sense because this is so not XML in so so many different ways. So this specific auto-detect failure is something we could fix upstream.
    – Josh Goebel
    Commented Oct 17, 2020 at 18:15
  • 1
    Filed as an upstream issue: github.com/highlightjs/highlight.js/issues/2767
    – Josh Goebel
    Commented Oct 17, 2020 at 18:19
  • 1
    There is a PR to fix this that will be merged soon and will be released when 10.4 is out. Markdown was also far too "greedy" and claiming anything that looked like [x][y] as a link. This has been resolved.
    – Josh Goebel
    Commented Oct 28, 2020 at 2:54
1

C# Stack Trace in Log File Formatting is Wrong

See What does "Keyword not supported: 'endpoint'" mean and how does it relate to the "messaging" connectionstring?

This is a log file that contains a C# stack trace. It doesn't seem to pick up C# as the language and highlights it wrong.

Improve this answer
2
  • 3
    This is correct behavior. If no language is specified, it has always attempted to highlight with a "default" that covers most language generics. You can always specify the language manually.
    – animuson StaffMod
    Commented Sep 25, 2020 at 14:32
  • Actually the "best match" is found and that is used for highlighting. So if your code "looks like" Python in our [Highlight.js] opinion, they you will get Python highlighting. As mentioned the best way to always get the correct highlighting is to specify the language manually.
    – Josh Goebel
    Commented Oct 17, 2020 at 18:04
-1

I ran across the following code in this question.

You can see the coloring is not formatted properly:

<form method="post">
   <div class="form-group">
       <label for="title">Numéro</label>
       <input type="number" name="NUMERO"
              placeholder="666, etc" class="form-control" required
              value="{{ request.form['NUMERO'] }}"/>
   </div>
<div class="form-group">
       <label for="TYPE_VOIE">Type voie</label>
       <select class="form-control" id="TYPE_VOIE" required >
          <option>Rue</option>
          <option>Impasse</option>
          <option>Place</option>
          <option>Boulevard</option>
          <option>Avenue</option>
      </select>  value="{{ request.form['TYPE_VOIE'] }}"
</div>

Enter image description here

Improve this answer
8
  • 2
    This isn’t a bug, the question is tagged as flask, so Stack Overflow (reasonably) infers that the code in the question should be Python. I’ve fixed the formatting now by correcting the markup in the question.
    – Konrad Rudolph
    Commented Oct 7, 2020 at 21:05
  • How is this not a bug? It has incorrectly identified the code as Python when it is obviously HTML. The question is also tagged with bootstrap-4. Why would prioritizing the Flask over bootstrap-4 tag be correct?
    – noslenkwah
    Commented Oct 7, 2020 at 21:10
  • 1
    Also, Flask is a web framework. Maybe it would be better to narrow down the possible code types to Python, HTML, Javascript, and CSS, instead of assuming all code has to be Python.
    – noslenkwah
    Commented Oct 7, 2020 at 21:17
  • Fair enough I guess (to be clear: I agree that Stack Overflow really should be doing this better, it’s embarrassing that the world’s largest (and most flush with cash!) programming QA website can’t even remotely get syntax highlighting right, ugh) but the heuristic for detecting languages has always worked like this, and the change of highlighting engine didn’t cause this mis-detection.
    – Konrad Rudolph
    Commented Oct 7, 2020 at 21:17
  • Quickly checked the last 3 questions posted with the Flask tag. All 3 of them have code other than Python in the questions (1, 2, 3)
    – noslenkwah
    Commented Oct 7, 2020 at 21:21
  • Perhaps I decided to pay more attention to the formatting since they made the change.
    – noslenkwah
    Commented Oct 7, 2020 at 21:22
  • @noslenkwah: It is not pure HTML. It is HTML mixed with the Django template language - the {{ ... }} part. (It can be anywhere, not just inside a string)
    – This_is_NOT_a_forum
    Commented Oct 12, 2020 at 12:59
  • @P.Mort.-forgotClayShirky_q: It's more likely jinja2 given that the question is about Flask. Regardless it clearly isn't formatted in any useful manner. Formatting as HTML where the small bits of templating language are left unformatted is clearly more useful than how it is currently formatted.
    – noslenkwah
    Commented Oct 12, 2020 at 13:18
1
2

You must log in to answer this question.

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