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.
Aquí está el error de Nokogiri presentado en su nombre según su solicitud:
¿Podrías por favor enviarme la salida de nokogiri -v, ya que eso es lo que necesitan los desarrolladores allí.
Me siento como un servidor SMTP humano reenviando mensajes entre dos servidores que definitivamente no están hablando entre sí
Desde mi punto de vista, funciona en el navegador debido a un comportamiento inesperado del navegador, no a una característica de HTML; el elemento strike no está diseñado para abarcar divs y párrafos.
Entendido. 
Y si el grupo Nokigiri implementa esta solicitud de función, eventualmente se filtrará a Discourse. Así que, ¿puedo tener la salida de:
nokogiri -v
por favor? Tengo que agregarla a la descripción del error, tal como lo solicitaron tú y Nokigiri, porque desde la perspectiva de un usuario final, esto ahora parece un engaño en Discourse:
(Ten en cuenta la vista previa y la salida final)
No apoyo el cambio de Nokogiri; si es necesario debido a múltiples quejas de clientes, podemos sanitizar estos elementos para que la vista previa coincida, o abrir incidencias en Chrome y Firefox.
También es aceptable sanitizar la entrada de la vista previa:
Basta de interacción con el usuario final estúpida por hoy: te dejo que vuelvas a cosas más importantes como el desarrollo real… 
@sam Como se acordó en la conversación fuera de línea, se abrió un problema en nokogiri, quien nos indicó que en realidad es CRuby quien utiliza libxml2.
Por lo tanto, se abrió un nuevo problema en libxml2 para que eventualmente sea incorporado por nokogiri, y así Discourse y @alexs @codinghorror @mattman @Mittineague @riking puedan ser personas más felices para que el tachado funcione en múltiples líneas.
Mis disculpas a todos por ser tan pedante al respecto, pero:
Las personas fáciles se adaptan a su entorno, mientras que las personas difíciles insisten en que su entorno se adapte a ellas. Por lo tanto, todo el progreso humano, desde la domesticación del fuego, la rueda, las pirámides, la penicilina, … hasta forzar electrones a través de un túnel cuántico para darnos almacenamiento SSD puede atribuirse a las personas difíciles!
