Multi-Line Strikethrough Not Covering Quotes

I’m not sure whether this bug is specific to Discourse but when I try to strikethrough several lines of text & one of those lines is a quote, the quote’s text is not struck out.

The preview displays the quoted text as struck out -

but when posted, it renders like this -

Striking out each line instead like this -

does behave as I was expecting -

1 Like

You should really try that example at

As that is the site testing implementing the common mark spec into Discourse.


Works fine in


I’m still having the same issue in, in your example you haven’t got struck out text before the quote but in mine, I have -

looks like

From this topic -


Looks like nokogiri may be messing stuff up, I will investigate.


Let’s see

Some text

a quote


<s>Some text

> a quote


This still happens.

1 Like

Strike is an inline, not a block level element, I may just add a rule to balance inline tags


So this is still a thing. The preview is different from the final product.

1 Like

Simple workaround, use strikethrough as a line not block element.

Rather than expecting this to work

> there

Strikethrough each line instead

> <s>there</s>



1 Like

Thanks, but I wasn’t asking for a work around. I was pointing out that this bug still exists. It’s weird that the preview gets it right but the actual render doesn’t.


It’s unlikely we will be “fixing” this bug anytime soon, so plan accordingly :wink:


I’m not so sure this is a bug. Phrasing content can’t be expected to work well with Flow content that is not itself Phrasing content. eg. <div> or <p> tags.

What would be required is to parse the single opening and closing <s> tags to multiple tags within the parent Flow content elements.

IMHO, that is most likely a bit much for something that is edge case and has an existing workaround.


What’s happening is the browser is applying an age-old fix by copying the <s> onto each paragraph until the close tag. The server uses Nokogiri which does not Reconstruct the active formatting elements but instead inserts a close tag for the strikethrough at the end of paragraph, as you would for any non-formatting mis-nested tag.

It’s officially specified as applying to a, b, big, code, em, font, i, nobr, s, small, strike, strong, tt, and u.



I am not against somebody submitting a patch nokogiri that works around this issue, or gives it a mode where it is able to handle it and we use it.

But I am moving this to feature … cause technically you provided bad HTML, if anyone is passionate about this raise it on the CommonMark site or Nokogiri bug tracker.


Here’s the Nokogiri bug filed on your behalf as per your request:

Could you please come back to me with the output of nokogiri -v as that’s what the developers over there need.

I feel like a human SMTP server forwarding messages between 2 servers who are definitely not talking to one another

:stuck_out_tongue_winking_eye: :crazy_face:

1 Like

The way I see it, it works in the browser due to a browser quirk, not an HTML feature, strike is not meant to span divs and paragraphs


Understood. :innocent: And if the Nokigiri group implements this feature request, this will eventually dribble down to Discourse. So can I have the:

nokogiri -v 

output please as I have to add this to the bug description as per your and Nokigiri’s request because from an end-user perspective this now looks like a bait-and-switch in discourse:

(Please note the preview and final output)


I don’t support changing nokogiri, if we must due to multiple customer complaints, we can sanitize these elements so preview matches, or open bugs with chrome and Firefox


Sanitizing preview input is acceptable too:

  • at least it’s consistent from a UI perspective.
  • It’s not what I want, but it’s something I’ll have to live with…

:grin: :innocent:

Enough dumb end-user interaction for the day: I’ll let you get back to more important things like actual development:wink:

@sam As per off-line discussion, issue was opened with nokogiri, who told us it’s actually CRuby which is using libxml2.

Therefore a new issue was opened over at libxlm2 so that eventually it’ll get pulled in by nokogiri, then discourse and @alexs @codinghorror @mattman @Mittineague @riking can all be happier people for strikethrough to work over multiple lines

My apologies to everyone to be so pedantic about this but:

Easy people adapt themselves to their environment, whereas difficult people insist their environment adapts to them. Therefore, all human progress, from the taming of fire, the wheel, the pyramids, penicilline, … up to forcing electrons down a quantum tunnel to give us SSD storage can be attributed to difficult people!

:grin: :wink: