The line that starts with <s>::::::Well, I've been away and tried to make sense of both the article is not properly indented. Instead, it literally shows the colons. So that line has a problem. The markup of that line and the following lines is basically:

<s>::::::strikethrough
:::::: strikethrough
:::::: strikethrough</s><small>no_strikethrough</small>
::::::: no_strikethrough

The problem does not happen with:

::::::<s>strikethrough
:::::: strikethrough
:::::: strikethrough</s><small>no_strikethrough</small>
::::::: no_strikethrough

[: indents text](https://www.mediawiki.org/wiki/Help:Formatting). The parser seems to translate :text to <dl><dd>text</dd></dl> in HTML but the element <dl> is not allowed as a child of element <s>.

I don't think that's something to fix in the MediaWiki software.

@Aklapper I apologize if my bug-description was not sufficiently clear.

You misunderstood the problem, resulting in incorrectly retitling the task. Please see this revision with the colons removed. The bug still exists. The revision with the colons removed would (theoretically) result in a new task titled "Wiki text: <s>makes rest of the text on the page strike-through".

The report was never about the colons after the <s>, there is no request to change how they are handled. They are handled as-expected.

The bug is that the </s> is ignored, that's what's mangling the page. Not only does it mangle the page but it causes a disruptive time-sink for editors trying to find tag-mismatch in the wikitext. Of course no tag-mismatch can be found, and no other error can be located, because there is no error in the wikitext.

For approximately everyone (except for apparently some programmers), it is incomprehensible and clearly wrong that the </s> tag fails to work.

Please correct the task title and reopen the bug. Thanx.

See https://www.mediawiki.org/wiki/How_to_report_a_bug how to structure tasks to avoid misunderstandings. :)

@Alsee: The </s> is ignored because the <s> is in the wrong place, as I wrote in my previous comment and also showed in a wikitext example.
Hence the status and title of this task is correct, pointing to the reason for the problem and not to the outcome.

@Aklapper you can see in another revision from Admin noticeboard the bottom of the page is mangled even when the opening tag is placed after the colons.

I would like to place a added emphasis here in on new editors. While there have sometimes been some differences of opinion on how to best serve new users, new users are consider extremely important to the community and I expect essentially universal agreement against user-hostile changes to the software. Perhaps it would help if I opened a community discussion to seek evaluation and consensus on whether the wikitext in these examples is expected to work? I believe there will be general consensus that the current behavior is hostile both for established editors, and hostile to new users. In the examples given, no average person can be expected to be able to figure out why the closing tags don't work. Especially when they used to work.

In T230010#5402361, @Alsee wrote:

@Aklapper you can see in another revision from Admin noticeboard the bottom of the page is mangled even when the opening tag is placed after the colons.

I cannot see an obvious problem from taking a quick look, so if there is some problem please follow https://www.mediawiki.org/wiki/How_to_report_a_bug and provide steps to reproduce (pretty clear here already), what exactly you expect to see and where, and what you see instead. Thanks!

I would like to place a added emphasis here in on new editors. While there have sometimes been some differences of opinion on how to best serve new users, new users are consider extremely important to the community and I expect essentially universal agreement against user-hostile changes to the software. Perhaps it would help if I opened a community discussion to seek evaluation and consensus on whether the wikitext in these examples is expected to work? I believe there will be general consensus that the current behavior is hostile both for established editors, and hostile to new users. In the examples given, no average person can be expected to be able to figure out why the closing tags don't work. Especially when they used to work.

I agree with the sentiment. However I don't think that working around invalid HTML should be a priority for the parser code.

@Aklapper, this example involved the small tag instead of strikethough, so it was perhaps less obvious on a "quick look".

Here's the critical portion of the page:

:::::<small>For over ten years; but he does not boast about it. [[User:Fortuna Imperatrix Mundi|_{'''<font color="green">Fortuna<font color="green"></font></font>'''}]] ^{'''''[[User talk:Fortuna Imperatrix Mundi|<font color="red">Imperatrix Mundi</font>]]'''''} 15:59, 12 December 2014 (UTC)

:::::::</small>Golbez is far too valuable as a map-maker at WP to imagine anything but deference ultimately from any editor. I am trying to construct an argument based on sources; I pretty certain of my reading of them. I initiated a compromise to accept EITHER --- '''a)''' including territories in the Infobox area and population WITH “50 states and DC” footnoted, — or --- '''b)''' “50 states and DC” in the info box area and population WITH figures including territories footnoted, — based on the sources.

What I expect expect to see: I expect to see text in small font style in between the matched tag-pair <small> and </small>. I expect text outside of the matched tag pair to appear in default font. And while it is not relevant here, I expect an unmatched <small> tag would cause the small style to run down to the bottom of the page.

What I see instead: The closing tag doesn't work, the font style spills to the bottom of the page. The last five and a half sections are incorrectly styled as small.

Note that this is the same bug I described in the task. You made various comments focused on the placement of the opening tag. My second link showed that the bug still existed when the colons were deleted, and this latest example is showing that the bug still exists when the opening tag is indisputably-correctly-placed after the colons.

The bug is about how the closing tag is processed (or more accurately, how the close tag is not being applied). The bug is that approximately 100% of experienced or learner-editors would expect the closing tag to work in each of these examples. The bug is they would find it disruptively confusing trying to figure out why their trivially-simple and trivially-clear edit broke the page.

The point of a wiki is that people aren't supposed to need a programming degree to edit. Simple markup should to do what it looks like it does. All of these examples used to work as expected. Now it's broken and confusing to the point of incomprehensibly-bizarre for virtually any new or experienced editor.

Personally I agree that people aren't supposed to need a programming degree to edit and hence should not have to learn about markup like <s> or using colons to indent lines. I guess that's why visual interfaces like VisualEditor or Flow or LiquidThreads or WikiEditor got developed to avoid those issues that you describe.

I realize this issue has already been discussed in T199057, hence closing this task as a duplicate.