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)

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.

3 إعجابات

Works fine in Markdown.it

3 إعجابات

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

4 إعجابات

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

7 إعجابات

Let’s see

Some text

a quote

raw

<s>Some text

> a quote

</s>

This still happens.

إعجاب واحد (1)

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

إعجابَين (2)

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

إعجاب واحد (1)

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

إعجاب واحد (1)

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.

إعجابَين (2)

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

إعجابَين (2)

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.

3 إعجابات

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.

See https://html.spec.whatwg.org/multipage/parsing.html#misnested-tags:-b-i-/b-/i:reconstruct-the-active-formatting-elements

5 إعجابات

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.

6 إعجابات

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

:stuck_out_tongue_winking_eye: :crazy_face:

إعجاب واحد (1)

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

3 إعجابات

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)

:sob:

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

:thinking:

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:

6 إعجابات