6

I have plenty of old answers where I used <pre><code> to format code, with HTML tags such as <b> or <strike> inside such blocks.

That has been broken for some time now, on SO as well as on dba.SE. It's particularly annoying where it completely breaks the meaning. Like here:

This used to work, but now renders without the strike-through (and bold) format, basically breaking my answer.

Original code:

<pre><code>...
GROUP BY model.name, attempt.type, <strike><b>attempt.result</b></strike>
...</code></pre>

Expected result (except for missing syntax highlighting):

...
GROUP BY model.name, attempt.type, attempt.result
...

Actual result:

...
GROUP BY model.name, attempt.type, attempt.result
...

Demo with more details:

The result should really get syntax highlighting for the declared (or derived) language and added manual formatting. It used to work like that.

This happens because the syntax highlighter, Highlight.js, strips all tags before adding colors. The code renders just fine here on Meta.SE since highlighting is off by default. But it can be reproduced by declaring a language in an HTML comment. OTOH, after disabling highlighting for the block or post using <!-- language[-all]: lang-none --> manual HTML tags are kept.

Also, while editing, the local rendering of the preview honors HTML tags until the draft is saved and syntax highlighting kicks in. I wouldn't mind that for stylistic details. But I do mind completely breaking some of my answers.

These FAQ answers on meta.SE and meta.SO still suggest <pre><code> for code blocks, without mentioning the severe side-effects:

(I have since edited both to reflect current behaviour.)
How to unbreak?

Update: This bug was reported to the authors of Highlight.js, who responded that SE needs to implement a plugin on their end to fix this issue.

Improve this question
21
  • 4
    It looks to be Highlight.js that is overriding the tags to add coloring. It doesn't happen here on Meta because the code block doesn't get highlighted.
    – animuson StaffMod
    Apr 21, 2022 at 0:51
  • 3
    As a temporary workaround for this bug, one can place <!-- language-all: lang-none --> to disable syntax highlighting for the post: I've suggested an edit to your linked post that does so.
    – Sonic the Anonymous Hedgehog
    Apr 21, 2022 at 0:58
  • 1
    Also, to address a couple things: 1. It works in the post preview because syntax highlighting doesn't kick in until a 5-second waiting period. 2. It (probably) used to work in the past because the system now uses a different syntax highlighter, Highlight.js, and the previous highlighter, Prettify, probably supported it just fine.
    – Sonic the Anonymous Hedgehog
    Apr 21, 2022 at 1:01
  • 2
    I've filed an issue on the highlight.js repository for this bug.
    – Sonic the Anonymous Hedgehog
    Apr 21, 2022 at 1:25
  • @SonictheSaveUkraine-hog: Thanks for the workaround! Good to know. A solution would be even better ... And yes, the issue is definitely linked to the switch from Prettify to Highlight.js.
    – Erwin Brandstetter
    Apr 21, 2022 at 1:25
  • 2
    This is a known issue. It's why syntax highlighting was turned off in the review queues months ago, where it removed the difference highlighting between post versions. I don't recall if there's a general bug report for this wrt. places outside of the review queues.
    – Makyen
    Apr 21, 2022 at 1:46
  • 1
    Barring Highlight.js rewriting their code, there is unfortunately no solution / workaround toget both. Highlight.js explicitly pulls textContent of the element to be highlighted, which loses all HTML by design. There is nothing we can do about it.
    – animuson StaffMod
    Apr 21, 2022 at 3:24
  • I don't think you are supposed to add formatting to code. The same can be achieved by other means.
    – This_is_NOT_a_forum
    Apr 21, 2022 at 9:14
  • @animuson Yeah, I figured as much, which is why I filed the issue in the Highlight.js repository linked above.
    – Sonic the Anonymous Hedgehog
    Apr 21, 2022 at 9:20
  • 2
    @animuson As I also answered on the GitHub issue this behavior is trivial to add via a custom plug-in (and the before/afterHighlightElement hooks), so if Stack Overflow truly desired this behavior they could have it with minimal effort. We have plugin APIs specifically to allow these kind of things to live outside of the core library.
    – Josh Goebel
    Apr 21, 2022 at 11:27
  • 2
    @JoshGoebel Interesting. It is certainly helpful that a plugin already exists. Though we would probably need to investigate how often users even do this on our sites to determine if it is worthwhile to add a plugin for it (and the additonal bandwidth associated). We may just stick to choose one or the other.
    – animuson StaffMod
    Apr 21, 2022 at 16:57
  • 1
    Sure. @ErwinBrandstetter Another idea might be to use a diff to showcase the changes you wish someone to make instead of embedding strike markup.
    – Josh Goebel
    Apr 21, 2022 at 19:44
  • I've started a discussion on Meta.SO regarding this issue. (cc @JoshGoebel)
    – Sonic the Anonymous Hedgehog
    Apr 21, 2022 at 20:21
  • @animuson Obviously, hardly anybody "does it" while it doesn't work. Some did it while it worked, and those posts are (partly) broken now. (While it's still advertized in the FAQ.)
    – Erwin Brandstetter
    Apr 21, 2022 at 20:52
  • 1
    @Erwin That's what I meant. This worked for much, much longer than it didn't work. So there should be a plentiful sample to look at for analysis of whether it's a feature that needs to be brought back. // I'm confused where exactly in the FAQ it says you are allowed to use this. It should definitely be removed as this is currently by-design behavior (that is unlikely to change in the near future).
    – animuson StaffMod
    Apr 21, 2022 at 20:56

0

Reset to default

You must log in to answer this question.

Browse other questions tagged .