CommonMark testing started here!

If you don’t rebake old posts they will keep the current generated HTML.


And become a time bomb, waiting to break in the future.


I’ve already seen a topic of mine here on Meta break. Sub-bullets now need two spaces, not one, so when someone edited a wiki post of mine my bulleted list broke.

I wonder @sam if any sort of migration script is planned?

1 Like

Very super undecided on a migration script. The concern I have is that it is possible a migration script can mess stuff up more than it will actually help.

I am semi open to making a script that fixes up bad multiline quotes (one’s that start mid line) and maybe the title thing.

Will think about it.


If you store bake time and switch to new engine time, you can punt on a script to deal with later, or to just highlight warnings when appropriate.

“You are editing a post that predates the current parser. Please double check that the syntax still works as expected.”


No, this is not needed at all. I would not bother. People can fix up the rare affected posts themselves.


@sam, can you think of a better way than to deal with two checked items in the checklist producing italized content without escaping the *?

I plan to mess around with the plugin a bit more this week, but I may just ditch trying to support backwards compatability and just wait for the markdown-it to be official and default. I’ve used the approach in the past, by simply tagging a prior version of the plugin and older installs can utilize that (if they are not ready to upgrade).


@Vitaly I have come across an interesting edge case here.

At Discourse we use “raw” html for images cause we need to specify size and sadly you can not specify size in CommonMark (which for the record makes me super :sadpanda:)

So if you have:

<img src="//" width="202" height="148">
<img src="//" width="202" height="148">  
<img src="//" width="202" height="148">

It will render as:

Despite newline being enabled here. This happens cause there is no “inline” defined for the images.

I can work around with:

<img src="//" width="202" height="148">&nbsp;
<img src="//" width="202" height="148">  
<img src="//" width="202" height="148">


I guess I just need a custom inline rule here that wraps and <img in an inline.

Also opened this up:

Do you need to specify any possible size or select from pre-defined set?

I think we need to split problem. Is it about:

  • sepecifying custom image size
  • line breaks between <img> tags
  • both


I need to specify any possible size, this becomes super critical stable layout on the page.

I guess what you are trying to determine here is if we could have a custom post processing job that injects size into the HTML and takes this decision away from the user.

My answer to this would be … maybe… If you upload retina you want to specify the smaller size so the retina screens get high fidelity and non-retina just get scaled down. It is possible we could glue this information into an EXIF tag or something and then have a post processor magic an SRCSET. But it would be a huge change.

line breaks between <img> tags

We absolutely need to deal with this cause we have tons of history, I can hack html_block.js to support this edge condition quite easily. But I also think the spec needs an adjustment here.

sepecifying custom image size

I also think the spec should deal with this, especially cause of the HiDPI concern.

In general, everything is blocked by spec. I can explain solutions i know, but all those are not ideal.

Image size can be defined:

  • via html
    • Not convenient.
  • via maruku-like syntax ({attrs} after any markdown element, see “consistend attributes syntax” thread at CM forum)
    • Require parser core update for correct work. Such deep core updates are not welcome without spec change
    • This open the road to tons of vulnerabilities without sanitizer. That’s the main reason why i don’t like this feature to be enabled by default.
    • Can be hacked via image rule replace, but that’s too dirty, because code itself is a bit complicated.
    • Not sure this will ever go to spec.
  • via alt attribute content
    • [alt text|100x200](http://....), [alt text|small](http://....)

So, i described the situation, but don’t like to take responsibility for your choice. IMHO, right now every choice is not ok. Because problem is on spec level, and i can’t push it forward. In nodeca, i decided to use alt content, but only to select between predefined sm|md|orig sizes, not to set WxH. Also, nodeca does not pretend to define de-facto standards.

About keeping breaks between <img> tags. IMHO it’s impossible to solve this problem easy on spec level. Because if you have a line with <img> tag only, it’s impossible to say, is it a raw block, or paragraph with raw inline element. I think, right now it’s better to hack html_block rule to filter out <img> tags - more easy to update in future.


Thanks heaps, totally understand, we are just stuck with no ideal solution here.

I really like this syntax proposal cause it is far simpler to parse and the Markdown looks much cleaner. Sure it is not as “flexible” as maruku like syntax but it is far prettier. I think we may migrate to it.

1 Like

What is the specific markdown that you have that is failing?

[] Item One
[*] Item Two (should be checked)
[ ] Item Three
[*] Item Four (should also be checked)

Without escaping the * on one of the two items, it causes the text Item Two, Item Three to be rendered as italic and therefore the [*] doesn’t render as a checked checkbox, but rather []

If there was a way to force my rules to apply before <em> gets applied to *, it would solve my issue, as my rendered output would negate the parsing of * into <em>. But I’m not sure that is really advisable.

This is a GIANT conundrum.


[] Item One
[*] Item Two (should be checked)
[ ] Item Three
[*] Item Four (should also be checked)

Item One
[] Item Two (should be checked)
[ ] Item Three
] Item Four (should also be checked)

At the moment I changed it so we apply the checkboxes AFTER all the inlines happen.

Otherwise stuff like[*] would be rendered as a checkbox which is far from desirable.

We can easily push it up in the chain so it happens prior to applying italics, but then we break automatic links.

The “standard” unofficial plugin also does the application in a core rule (I assume for the link reason)

I really don’t think this can be resolved, I would recommend just documenting this issue. A newline here would fix it anyway or making it a list or escaping.

@Vitaly any thoughts here about the checkbox plugin?

1 Like

OK I fixed the img tag by adding this new block rule.

It is not ideal, but at least it is reasonably defined and does not mess with the core of Markdown it.

1 Like

That may need format clarification. For example, to allow px, em, rem if needed. I provided only demo to explain principle. Don’t remember details. Seems, CM forum may have threads with more examples.

I’m 100% okay with going the escaping route, I’ll just drop backwards compatibility support as I don’t really have a lot of time to dig into why it isn’t working quite right without markdown-it enabled (feels like something magical and not a simple mistake on my part). Plus it would keep the plugin a bit cleaner and those who do not wish to upgrade (or can’t), can reference a tag to stay on their current version.

I’ve done that in the past, it hasn’t caused any major issues (to date).

On the other hand, I guess I could change the default behavior to mark checked with [x] instead of [*] and that would solve the issue without the need for escaping. I’d probably have to ask the users of the checklist-plugin about that sort of change though. (ping @meglio, @andrejkosyak, @steven, @downey, @Trash)

Then [*] would only be an issue for existing checklists and/or manually updating/creating them and the preview window would be indicative enough to hint you need to escape the *.

1 Like

Known (unresolved) issues are:

  1. What is proper html5 markup for the list of checkboxes?
  2. How to properly update source when user click checkbox (as on github).

I consider such plugin useful, but i not implemented it due lack of good spec. Seems, someone published implementation in npm registry, but can’t comment anything about quality.