5

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

1 Answer 1

Reset to default
3

This is now .

Stack Exchange implemented the plugin pointed to in a comment by the Highlight.js maintainer and described in their comment on my GitHub issue. The main goal was to fix the issue of diffs not correctly retaining removal and addition formatting, but as commented there, the fix was global - it links to a formatting sandbox answer which demonstrates it working.

Improve this answer
8
  • That sums up the current (coincidental) state. I would love an official statement as to whether HTML formatting is here to stay. I tried to get a definitive answer from a staff member, but no such luck.
    – Erwin Brandstetter
    Aug 7 at 21:35
  • @ErwinBrandstetter It seems that you didn't take that comment conversation at face value. I read "Thanks for following on that. I can confirm that HTML styling in explicit <pre><code> blocks will work. If you find issues with that, please let us know. On the other hand, we do not support HTML styling in actual code blocks (```). Hope that helps!" — marrados ♦ Mar 23 at 16:47 as a clear, official statement that it's working and will continue to work.
    – Makyen
    Aug 9 at 4:38
  • @Makyen There's a bit of an ambiguous interpretation there. The way you wrote it was how I took it as well, but another way to interpret it is that "this just happens to work due to the current changes; it is not an official part of the design and is subject to break again if we change things there".
    – Sonic the Anonymous Hedgehog
    Aug 9 at 4:45
  • 1
    @SonictheAnonymousHedgehog I disagree with the latter interpretation. That's the developer saying "Yes, that works. We fixed that. If there are any problems, please let us know." The caveat of "it might break again if we change things" exists for everything.
    – Makyen
    Aug 9 at 4:54
  • @Makyen Yeah, I was about to respond to their comment that I interpreted it the way you did, but you commented first. I was just trying to explain the author's (possible) perspective.
    – Sonic the Anonymous Hedgehog
    Aug 9 at 4:55
  • @Makyen: Something in the FAQ, formatting guidelines, or some other official source - that's what I would call "official". A comment hidden in the depths of meta.SO - not so much. Nor was it clear. The staff member just confirmed what I had found out the hard way myself. I asked clear questions, that went unanswered. After so much of my time and effort had been wasted by this negligence, this was closer to insult than consolation. The state of affairs is unclear to me to this day.
    – Erwin Brandstetter
    Aug 9 at 4:56
  • 1
    @ErwinBrandstetter The FAQs are meant to be maintained by the community and the formatting guidelines are intended to be short and describe the most important elements and do leave a few of the details of lesser-used elements out. Also, it's not unusual for official things to be left in staff comments, such as this comment announcing a change to the number of answers required to trigger a warning of too many answers to a question. Finally, I don't see what was unanswered- was I correct in my previous comment on your interpretation?
    – Sonic the Anonymous Hedgehog
    Aug 9 at 5:02
  • 1
    You got an answer to your questions that's way better than it being in the community maintained FAQ. That's the sort of statement – yes, that comment – from which the community FAQs are created.
    – Makyen
    Aug 9 at 5:04

You must log in to answer this question.

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