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 https://markdown-it.discourse.org

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

3 Likes

Works fine in Markdown.it

3 Likes

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 Likes

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

7 Likes

Let’s see

Some text

a quote

raw

<s>Some text

> a quote

</s>

This still happens.

1 Like

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

2 Likes

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

<s>
hey
> there
</s>

Strikethrough each line instead

<s>hey</s>
> <s>there</s>

hey

there

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.

1 Like

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

2 Likes

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 Likes

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 Likes

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 Likes

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:

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 Likes

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 Likes