ayg wrote:

I have a writeup at [[User:Simetrical/9737]]. The behavior is rather bizarre,
but I doubt we want to hack Tidy to fix it. Maybe if there's a configuration
option or something, marginally, but the bottom line should be don't wrap block
elements like lists in inline elements like <span> (use <div> instead). Tidy
will try to make sense of it, but it's going to be an uphill battle, and you'll
have some screwed up results like this in particular cases. (The exact trigger
case, incidentally, is an ordered list wrapped in an inline-level element with
an id. Remove the id, or use anything but an ordered list, and you'll have no
visible strangeness.)

Not our bug, not reasonably fixable by us given its lack of severity, INVALID.

ayg wrote:

*** Bug 10077 has been marked as a duplicate of this bug. ***

ayg wrote:

Also sometimes happens with <font color=...>, per bug 10077. URL updated. The same resolution reason applies.

*** Bug 10901 has been marked as a duplicate of this bug. ***

Did anyone contact the developers of HTML Tidy?

After trying unsuccessfully for quite some time to reproduce this bug outside MediaWiki (so that I could report it to the Tidy developers), I finally discovered that the bug is triggered by the presence of a newline at the end of the first list item(!). That is, the following input to Tidy triggers the bug:

<span id="xxx">
<ol><li>Foo
</li><li>Bar</li></ol>

...but the following doesn't:

<span id="xxx">
<ol><li>Foo</li><li>Bar</li></ol>

Thus, we probably _could_ work around it fairly easily by modifying Parser::doBlockLevels() so that the newline gets removed or moved after the </li>. Reopening in light of this.

Submitted to the HTML Tidy bug tracker as [http://sourceforge.net/tracker/index.php?func=detail&aid=1773932&group_id=27659&atid=390963].

Patch to Parser::doBlockLevels() to put newlines after close tags, to work around a bug in Tidy

I've made a quick parser patch that I believe should work around the bug. Some might even argue that it actually makes the output prettier. The reason I haven't committed it yet is that the change breaks about 390 parsertests, and I'm not _quite_ completely and absolutely certain yet that all of those are false alarms. Even if they are, the test cases would still need to be updated.

Attached:

The Tidy bug tracker (http://sourceforge.net/tracker/index.php?func=detail&aid=1773932&group_id=27659&atid=390963) says that this issue has been fixed in the CVS.

*** Bug 16815 has been marked as a duplicate of this bug. ***

• Bug 17417 has been marked as a duplicate of this bug. ***

Adding upstream keyword since that's what it is :)

Adding testme...has this indeed been fixed in released versions since #comment 9 (I would assume so)?

*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*

sumanah wrote:

screenshot of resulting page, should have shown 3 bullet points

The original steps-to-reproduce now show up as shown, so there's still a problem (if we want that formatting to work).

https://www.mediawiki.org/w/index.php?title=Sandbox&oldid=452753

Attached:

pravinxyz wrote:

This seems to be problem with IE only.

When I write:

#One
#Two
#Three

<font color=red>
#One
#Two
#Three
</font>

I see (screenshot in Firefox 32.0.2 on Win7):

and (screenshot in IE 8.0.7601 on Win7)

And when I copy and paste, I see:
One
Two
Three
One

Two
Three

Edited using below

Interesting Wiki Bug (look at the automatic numbering):

#One
#Two
#Three

<font color=red>
#One
#Two
#Three
</font>

BUG

1. One
2. Two
3. Three

SPAN
<span style="color: blue>

1. One
2. Two
3. Three

</span>

DIV

<div style="color:#0000FF">

1. One
2. Two
3. Three

</div>

Workaround

<font color=red>

One

#:

Two

#:

Three

</font>

<font color=blue>

One

#:

1. Two
2. Three

</font>

1. One
2. Two
3. Three

PRE

<pre style="color: red">

1. One
2. Two
3. Three

</pre>

• Bug 72172 has been marked as a duplicate of this bug. ***