I made a small edit of the post https://stackoverflow.com/revisions/25855713/5 that showed steps and sub steps as html headers, and noticed that after my change the steps start to be shown as plain text, e.g. #Step 1 - Understanding Basic Authentication.

I decided that it was caused by my changes and reverted to previous revision 4 created in 2016. Unfortunately the formatting wasn’t restored.

I am guessing that since 2016 Stackexchange replaced its markdown interpreter and stopped recognise # without spaces before text as headers. In the markdown documentation https://daringfireball.net/projects/markdown/syntax#header space after hashes is shown, but not documented and some implementations enforce space, but other do not enforce.

I believe that old html was cached and showed headers correctly before I touched the post.

If my explanation is correct, it will be good to run convertion to update all old posts:
For lines starting with 1-6 hashes without spaces before the text to insert single space after the hashes to make backward compatible support of hash headers.

  • 5
    SE migrated to CommonMark in mid-2020, and CommonMark is one of those implementations that requires a space after the hash signs to produce a heading. Per We're switching to CommonMark, they did make a migration script to automatically edit posts that weren't compliant, but if the post contained some difference that wasn't covered by the script, it was left alone. Apr 13, 2021 at 4:31
  • 1
    From the above question: Things might get funky when you're editing a post that renders differently with the new CommonMark renderer. Again, if we detected that a post would look differently when rendered with the new CommonMark renderer during the migration, we wouldn't save a new version of this post as part of the migration. This way, all posts continue to look the same when being viewed. However, once someone comes in and edits it, it will be rendered using the new CommonMark renderer and this might cause the post to look slightly different than what we had before. Apr 13, 2021 at 4:32
  • 1
    See this answer where I've explained this in detail, with a similar case. Apr 13, 2021 at 4:37
  • @SonictheCuriouserHedgehog, thanks, the links confirmed, what I’ve guessed. However my question is a change request suggesting to fix particular issue rather than acknowledge that some posts will be unexpectedly broken by unrelated editing. It took me some time to think, how can my changes broke layout of an existing post, and I prefer, if others would not have such issue. Apr 13, 2021 at 4:53
  • As mentioned, there was already an automatic migration script written that took into account common rules, including the one you mention. However, it didn't edit posts if the CommonMark rendered HTML after its edit wouldn't match the original cached HTML from earlier, which would occur if there was some other difference in the post which wasn't accounted for in the script. This was done so as to avoid unexpectedly mass-breaking a lot of posts. Apr 13, 2021 at 4:56
  • @SonictheCuriouserHedgehog, according the quote “ if we detected that a post would look differently when rendered with the new CommonMark renderer during the migration we wouldn't save a new version of this post as part of the migration” the migration didn’t try to fix any incompatibilities with new renderer Apr 13, 2021 at 4:58
  • That post also says: Then there are those posts that are written in a Markdown flavor that was cool for our current renderers but isn’t what CommonMark would expect. [...] We’re talking about ##headlines without spaces after the hashes and other minor oversights. For these posts, we’ve built a tool that automatically fixes these well-known issues by changing a post’s Markdown source directly and re-rendering the HTML of the post in question. Apr 13, 2021 at 5:00
  • @Michael ... it will be good to run convertion to update all old posts .... Part of the problem is that there are many ways to produce the same result as the hash, and different renderers for server side and user preview; along with the need for different scripts for different sections, posts, Tag excerpts, etc. --- that doesn't mean that we shouldn't do what we can, just that there will always be something missed and in need of repair (without ruining any inventive contortions the writer might have resorted to).
    – Rob
    Apr 13, 2021 at 5:32
  • 2
    I anticipated on this problem: meta.stackexchange.com/questions/361539/…
    – rene
    Apr 13, 2021 at 8:40

1 Answer 1


I don't see the value in doing this.

There are less then 4% of all posts that didn't get updated with the Commonmark migration:

With the auto-fixing utility we estimate that we’re going to land at over 96% of all network posts being rendered completely identical after migrating to CommonMark and using the new renderers.

From here.

Of that 4% only a fraction will ever be edited again, in those cases users can easily fix the headers themselves. If they don't do that someone else will notice, as the edit bumps the post to the frontpage.

  • 1
    “ in those cases users can easily fix the headers themselves.”. Unfortunately users will not understand, what’s wrong, why their unrelated changes cause formatting. I fully understand that during initial conversion they changes were conservative to avoid big-ban, but once issues are noticed by users, they should be addressed by automated conversion, not keep them as a delayed bomb Apr 13, 2021 at 8:48
  • 1
    @MichaelFreidgeim There was a plan to implement a warning on the edit pages of the 4% of posts, but it wasn't implemented due to technical constraints. Apr 13, 2021 at 16:57
  • @SonictheCuriouserHedgehog, thanks for information about the history how the problem arises. My concern is how to solve (or at least reduce) the problem. 4% is a huge number of posts, and keep html cache not in sync with source not good as a long term solution. Apr 13, 2021 at 22:38

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