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.
Hier ist der für Sie eingereichte Nokogiri-Fehler wie von Ihnen gewünscht:
Könnten Sie mir bitte die Ausgabe von nokogiri -v mitteilen? Das benötigen die Entwickler dort.
Ich fühle mich wie ein menschlicher SMTP-Server, der Nachrichten zwischen zwei Servern weiterleitet, die definitiv nicht miteinander kommunizieren
Meines Erachtens funktioniert das im Browser aufgrund eines Browser-Fehlers und nicht als HTML-Funktion. Das <strike>-Tag ist nicht dafür gedacht, <div>-Elemente und Absätze zu überspannen.
Verstanden. 
Und wenn die Nokigiri-Gruppe diese Funktionsanfrage umsetzt, wird dies schließlich auf Discourse übertragen. Kann ich also bitte die Ausgabe von:
nokogiri -v
erhalten? Ich muss dies gemäß Ihrer und Nokigiris Anfrage in die Fehlerbeschreibung aufnehmen, da dies aus Sicht des Endnutzers in Discourse nun wie ein Betrugsversuch aussieht:
(Bitte beachten Sie die Vorschau und die endgültige Ausgabe)
Ich unterstütze keine Änderung von Nokogiri. Falls wir aufgrund mehrerer Kundenbeschwerden dazu gezwungen sind, können wir diese Elemente bereinigen, damit die Vorschau übereinstimmt, oder Fehler bei Chrome und Firefox melden.
Auch das Bereinigen von Vorschau-Eingaben ist akzeptabel:
Genug blöde Endbenutzer-Interaktion für heute: Ich lasse Sie wieder zu wichtigeren Dingen zurückkehren, wie z. B. tatsächlicher Entwicklung… 
@sam Wie in der Offline-Diskussion besprochen, wurde ein Issue bei nokogiri eröffnet, wo uns mitgeteilt wurde, dass es eigentlich CRuby ist, das libxml2 verwendet.
Daher wurde ein neues Issue bei libxml2 eröffnet, damit es schließlich von nokogiri übernommen wird, dann von Discourse, und @alexs @codinghorror @mattman @Mittineague @riking können alle glücklicher sein, wenn durchgestrichener Text über mehrere Zeilen hinweg funktioniert.
Meine Entschuldigung an alle, so pedantisch dabei zu sein, aber:
Leichte Menschen passen sich an ihre Umgebung an, während schwierige Menschen darauf bestehen, dass sich ihre Umgebung an sie anpasst. Daher kann der gesamte menschliche Fortschritt – vom Zähmen des Feuers, dem Rad, den Pyramiden, dem Penicillin, … bis hin zum Erzwingen des Durchgangs von Elektronen durch einen Quantentunnel, um uns SSD-Speicher zu ermöglichen – auf schwierige Menschen zurückgeführt werden!
