Page MenuHomePhabricator

List not properly rendered to HTML on w:en:Template:Parties
Open, LowPublic


Template:Parties is a navbox on enwiki that uses flatlists (inside the navbox template) for formatting. An editor requested help because one of those flatlists wasn't flattening (permalink). Another editor and I scratched our heads at it for a while until I noticed that the relevant list had only <li></li> tags outside of any <ul></ul> tags in the rendered HTML for the first-level list:

<div style="padding:0em 0.25em">

      <a href="/wiki/Formal_wear" title="">Formal</a>
        <li><a href="/wiki/White_tie" title="">White tie</a></li>
        <li><a href="/wiki/Morning_dress" title="Morning dress">Morning dress</a></li>
      <a href="/wiki/Semi-formal_attire" class="mw-redirect" title="Semi-formal attire">Semi-formal</a>
        <li><a href="/wiki/Black_tie" title="Black tie">Black tie</a></li>
        <li><a href="/wiki/Stroller_(style)" class="mw-redirect" title="">Black lounge suit</a></li>
      <a href="/wiki/Informal_attire" class="mw-redirect" title="Informal attire">Informal</a>
        <li><a href="/wiki/Lounge_suit" class="mw-redirect" title="Lounge suit">Lounge suit</a></li>
    <li><i><a href="/wiki/Casual_wear" title="">Casual</a></i></li>


This meant that the display: inline; rule in the .hlist css never got applied to the first-level list. Adding <ul></ul> in the wikitext fixed the issue, but that's really only a hack around the issue.

Event Timeline

It's also worth noting that the page renders as expected when viewing using the REST API (

LGoto triaged this task as Low priority.Feb 14 2020, 5:21 PM
LGoto moved this task from Needs Triage to Known Differences on the Parsoid board.

This appears to be a known difference between Parsoid and the legacy parser: the legacy parser often wraps an outer list item around a bare <li>. That's not consistent with HTML5, which allows standalone <li> elements and does not wrap them. Parsoid uses standard HTML5 semantics, and the legacy parser is *much closer* to standard HTML5 semantics now that we're using Remex for tidy, but doBlockLevels in the legacy parser is a huge nightmare and there are obviously still corner cases.

You should insert an appropriate <ul> in the wikitext. This won't be fixed in Parsoid; and the core mediawiki will match the Parsoid rendering once we switch core to Parsoid.

(This is a quick analysis; feel free to correct me if I've misunderstood the situation.)

There should be no bare <li></li> elements in the parsed page since there are no such elements in the wikitext. Everything is built with * lists.

It looks like this is a legacy parser problem, not a Parsoid problem -- Parsoid parses the list reliably based on the REST API, the legacy parser didn't. Based on your description of the relevant legacy parser code, waiting for Parsoid in core seems reasonable.

I couldn't find a better project tag while creating the task, and I couldn't remember what was used where, so I misfiled the task. Apologies for the confusion from that.

Not a bug. Fixed with this edit:

Navboxes can't have bulleted lists hanging out after a subgroup without a list#= before them.