Take a look at the URL.
When you see the output page, the list has three items. If you edit it in the source editor, you'll see that there's an extra empty item in the end of the list. If you edit it in the VisualEditor, you'll see it rendered.
The VisualEditor behavior actually makes more sense to me. Gabriel Wicke suggested on IRC to open this issue at the PHP parser.
Version: 1.22.0
Severity: normal
URL: https://www.mediawiki.org/wiki/VisualEditor:Empty_list_item
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Izno | T7859 Rendering problem with empty list item and next section | |||
| Resolved | tstarling | T49673 Empty list items goes missing in the PHP parser when tidy is enabled |
I'm going to introduce a migration tool to fix this bug, roughly following @cscott's suggestion, which is to preserve empty <li> tags through Tidy, but to add a class to those preserved elements which will be styled with display:none. It is believed that there are some templates which are producing empty list items because it is convenient for them as a way of omitting the list item for empty input. After the display:none hack is introduced, a user script would allow the expected changes to be visible to template maintainers. There is also a proposed change to log affected templates: https://gerrit.wikimedia.org/r/#/c/246106
After a suitable migration period, the display:none rule would be removed, and list items would be visible as is desired by the multiple reporters of this bug.
The empty <li> tags would be preserved through tidy by adding a datafld attribute, exploiting special case behaviour in Tidy's CanPrune() which was intended to fix http://sourceforge.net/p/tidy/bugs/337/
Change 246148 had a related patch set uploaded (by Tim Starling):
Client-side migration for empty li preservaton
I don't have the gerrit skills to parse the code to understand whether this change will allow a page to emit a tracking category specific to monitor articles and templates that need to be updated. If it will, some instruction would be helpful. If it currently will not, please make whatever code modification is necessary to allow a page to emit such a tracking category. Thank you.
This tasks seems to be related to a lot of odd looking [[Template:Authority control]] templates that use hlists which suddenly started showing rows of dots between entries
The CSS trick for do not display element with mw-empty-li class works only for Desktop, not in mobile version.
It's possible in this transitory period hide the empty list elements also in mobile site? Thanks
See discussion (in italian) and example.
Change 253514 had a related patch set uploaded (by Legoktm):
Add 'mobile' target to 'mediawiki.raggett' module
Change 253514 merged by jenkins-bot:
Add 'mobile' target to 'mediawiki.raggett' module
There's no tracking category at the moment. I wanted to assess it myself, to determine the size of the problem, before creating task lists for others to work through.
Here is a log sample from parsoid listing some supposedly empty <li> elements. I have analysed some of them.
Here is a notable example of a template which depends on empty li removal. This navbox template allows the removal of countries from Europe depending on parameters. For example if you consider Germany to not be part of Europe, you can use {{Europe topic|DE=}} to make a navbox which omits the relevant list item. Note that you can't just take the asterisk inside the #if, because that would create paragraph breaks between adjacent list items. It could be done by taking the line break inside the #if, or by removing all the line breaks and using HTML-style <li> input.
It would be easier to fix such templates if we finally got around to allowing blank lines between list items without breaking the list. This has been requested very often, although unfortunately the narrower, more sensible proposals on the subject (e.g. T11342, T35918, T15223) have been closed as duplicates in favour of the more aggressive proposal T3115.
The goal of fixing templates to not emit empty list items in the first place ( T49673#1827449 ) is not in sight. For now, the core part of this ticket has been addressed. Empty elements no longer go missing with Tidy which means we can replace Tidy without worry about breaking rendering because of this.
Longer term, we should migrate to a CSS3 fix of li:empty { display:none; } and remove the mw-empty-elt class.