Last modified: 2009-11-17 22:43:36 UTC
Pre-XHTML HTML allows a number of elements to be implicitly closed,
such as <li> within a <ul> or <ol>.
In 1.5, MediaWiki allowed this code through:
While invalid XHTML due to not being well-formed, this did render
in browsers the way people would expect from traditional HTML.
In 1.6 and current trunk, this is smashed up in output as:
The second <li> and the closing </ul> are rejected and escaped, then closing
</li> and </ul> get added at the end of the document.
Proper application of nesting rules *should* normalize it to
something like this:
*note* because of question at
(Are <ul> and <li> even allowed on a default install?)
This bug can not be reproduced at Wikimedia Foundation wikies:
It can be seen at
best regards reinhardt [[user:gangleri]]
Fixed in trunk and REL1_6. We forgot to handle $htmlsingle
in Sanitizer.php :(
I'm not sure if this is the result of fixing this bug or a completely separate bug, but there's
another regression on both the latest 1.6 and trunk with either of:
The closing tags are shown (e.g. as <li) in the browser.
I'm reverting the bogus patch from REL1_6.
A parser change like this absolutely should NOT go into a release branch
without strict testing. There's not even a parser test case to go with it!
I've added 8 parser test cases. Currently only 1 passes, both in REL1_6
and trunk (which has the above and another patch hacked in).
At the moment trunk "looks" better for some cases but produces invalid
output, as 1.5 did.
I have a related problem (i believe it is related) with list parsing. Im using
wiki 1.6.3 but I believe it must be on 1.7. Sorry but i cant test 1.7 with
I have an extension to create MathML tags. It is called <asciimath>. when I do:
* item <asciimath>x</asciimath>
<ul><li>item <math ...(mathML)...></li> ... (math commands)... <math>
Or, for simplification:
As I need XHTML to get MathML working, my wiki page crash and burn.
1- it appears <li> closes after the 1st tag he encounter. it should at least
close before. It is not a very good solution.
2- <li> must allow tags inside him, SPECIALLY tags from extensions. It should
only look for:
- </ul> of the level hes in, not the children lists, or
...and place before it. Or, if he dont find it, destroy itself (by putting
<li></li> or removing the <li> unclosed.
*** Bug 5977 has been marked as a duplicate of this bug. ***
My bug report 5977 was marked a duplicate of this bug, which might be. But note
that even if the <li> tags are closed is the rendering not correct:
<li> Something else</li>
This is rendered as follows:
<li> Something else</li>
Created attachment 1885 [details]
New removeHtmlTags function which is mroe accurate and complete
Handles implied end tags properly, and obeys more nesting prohibitions.
Want to test this a little more before applying to trunk.
Created attachment 1891 [details]
With fix for crash on </body>
*** Bug 4373 has been marked as a duplicate of this bug. ***
This appears to still be an issues in 1.7.1 with definition lists. Any ETA on a
This appears to have been fixed long ago.