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 -
You should really try that example at https://markdown-it.discourse.org
As that is the site testing implementing the common mark spec into Discourse.
I’m still having the same issue in Markdown.it, in your example you haven’t got struck out text before the quote but in mine, I have -
looks like
From this topic -
https://markdown-it.discourse.org/t/testing-multi-line-strikethrough-with-quotes/90
Looks like nokogiri may be messing stuff up, I will investigate.
Let’s see
Some text
a quote
raw
<s>Some text
> a quote
</s>
This still happens.
Strike is an inline, not a block level element, I may just add a rule to balance inline tags
Simple workaround, use strikethrough as a line not block element.
Rather than expecting this to work
<s>
hey
> there
</s>
Strikethrough each line instead
<s>hey</s>
> <s>there</s>
hey
there
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 
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.
https://html.spec.whatwg.org/multipage/dom.html#flow-content
https://html.spec.whatwg.org/multipage/dom.html#phrasing-content
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:
https://github.com/sparklemotion/nokogiri/issues/1975
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
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. 
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:
Enough dumb end-user interaction for the day: I’ll let you get back to more important things like actual development…
@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!
