I think this is caused by the output looking different in this way:

Old:

<ol><li>Content
</li>
<li>Content
</li>
</ol>

Parsoid:

<ol><li>Content</li><li>Content</li></ol>

plus

.hlist li { white-space: nowrap }

Normal wikitext lists look fine for this, which I think is due to the whitespace between the list items.

<ol><li>Content
</li>
<li>Content
</li>
</ol>

Parsoid:

<ol>
<li>Content</li>
<li>Content</li>
</ol>

Indeed. This is almost certainly a wontfix. For Parsoid, they should probably disable the nowrap CSS rule.

I don't think that will fly. The nowrap keeps the li's contents from wrapping around lines, which is a desirable quality (and English Wikipedia would have it too but for using hlist in places where wrapping is a good thing rather than a bad).

It also keeps the ::after { content } from wrapping separately from the "normal" contents of the li.

Looks like this is very specific to Cite references output (from the navbox) and the CSS expects a newline between the "</li><li>".

This can be fixed in the CSS like this:

.mw-parser-output .hlist-pipe dd::after, .mw-parser-output .hlist-pipe li::after {
  content: " | ";
  font-weight: normal;
  white-space: break-spaces;
}

See the added white-space rule there, which ensures that the list items can be broken at the separators between them.

In T372889#10085265, @cscott wrote:

This can be fixed in the CSS like this:

.mw-parser-output .hlist-pipe dd::after, .mw-parser-output .hlist-pipe li::after {
  content: " | ";
  font-weight: normal;
  white-space: break-spaces;
}

See the added white-space rule there, which ensures that the list items can be broken at the separators between them.

It also keeps the ::after { content } from wrapping separately from the "normal" contents of the li.

Which is not resolved by your CSS. It's a feature that the pipes wrap with their lis.

@lzno which side of the <li> do you want the pipe to stick to? Just make the content: ... clause include a &nbsp; on the side where you don't want a break.

It looks to me like:

content: "\00a0| ";

is what is wanted, based on the legacy rendering.

Yes, that would work in LTR languages. I don't know about RTL. (I have no idea how RTL renders here before or after.)

I'm feeling kind of puzzled here. What's the reticence to adjusting the output in ParsoidCite to add \ns in reasonable places? As I noted, normal wikitext lists work as expected before and after, as does (obviously) Cite before. ParsoidCite's output is also pretty fully in your power to adjust, rather than having a bunch of edge cases like wikitext does.

Change #1065217 had a related patch set uploaded (by Subramanya Sastry; author: Subramanya Sastry):

[mediawiki/extensions/Cite@master] WIP: Parsoid: Add newline after every reference list item

https://gerrit.wikimedia.org/r/1065217

In T372889#10086597, @Izno wrote:

I'm feeling kind of puzzled here. What's the reticence to adjusting the output in ParsoidCite to add \ns in reasonable places? As I noted, normal wikitext lists work as expected before and after, as does (obviously) Cite before. ParsoidCite's output is also pretty fully in your power to adjust, rather than having a bunch of edge cases like wikitext does.

As I explained to @ssastry, I hadn't looked into whether this is consistent with our whitespace around <li> elsewhere. If this is just Cite-specific, sure. But if Cite was currently emitting "parsoid standard" markup for <li> I didn't want to make it into a weird special case.

As a matter of principal, I don't think the site CSS should be relying on nonsemantic whitespace. I agree that we should choose our battles, but I don't think there's a good argument in favor of jawikivoyage doing it the way they were previously doing it. Put another way, if you start inserting non-semantic whitespace there you can't ever get rid of it, or control it. If the whitespace was coming from wikitext, then you could add or remove it in wikitext to change the presence of the whitespace in HTML. But whitespace added "just because" becomes something out of the control of the editor.

Whereas, if you don't have nonsemantic whitespace there, there are a number of ways you can add it with CSS (including ::after rules) to get linebreaks if you want them, or add the whitespace to the wikitext, etc.

In any case, @ssastry confirmed that this isn't a "real" wikitext list, just the cite output for the references list.

So I'm fine with picking my battles here and accepting the whitespace insertion as a pragmatic solution since it is restricted to this one extension.

(Also as a matter of timing, adjusting the site CSS to fix the line breaks can be done immediately as an edit and doesn't require a code change + deploy, etc. Counterargument for that is that we're concerned that this same pattern might exist on other wikis, and we don't want to have to deal with editing the CSS in a dozen places.)

A counterargument to "fixing this in code" is that the stylesheet in question applies to a bunch of different hlists, some of which *will* be generated from wikitext.

https://ja.wikivoyage.org/w/index.php?title=%E3%83%86%E3%83%B3%E3%83%97%E3%83%AC%E3%83%BC%E3%83%88%3ANavbox%2Fstyles.css&diff=49718&oldid=31602
fixes this for all the hlists, not just the ones generated by Cite.

fixes this for all the hlists, not just the ones generated by Cite.

If all hlists needed fixing, then the rest of each of these navboxes would display the same issues as the use of hlist surrounding the Cite implementation. :)

Counterargument for that is that we're concerned that this same pattern might exist on other wikis, and we don't want to have to deal with editing the CSS in a dozen places.

It does. I alluded to this earlier in that I'd like to see en.wiki have this again some day, but the hlist as used there was originally designed like this. Which means other wikis copied that precise formulation. That en.wiki doesn't do it like that currently is due to hlist escaping from being solely navbox-oriented to sidebars and infoboxes, where space is more limited and I think in conjunction some issues with Internet Explorer AFAIK... which are obviously moot now. So it will make it onto the project list to review support for that.

So I'm fine with picking my battles here and accepting the whitespace insertion as a pragmatic solution since it is restricted to this one extension.

It may be the case that other extensions run into this, but I can't think of many that display lists in a place where they can be put into an hlist. Non extensions include __TOC__ and special page transclusions, but both output their lists with the items separated by new lines.

Looking at Scribunto uses, it looks like en.wp [[Module:List]] outputs its lists in a flat line, which uses the Scribunto mw.html library. New lines can be relatively easily inserted into that output I think (mw.html:newline), so that change is similarly trivial on a local level. But does mean either that module will need changing or the class definition will for the wikis with nowrap in their hlist definition. There are multiple other potential uses that people would need to be aware of, but I doubt many that are as general as that particular module.

Ya, I don't think this is a generic hlist issue -- Parsoid's HTML for wikitext lists already include the newline (the newline found in source wikitext) -- so I am not sure the hlist issue affects anything else. If it were, we would have heard this long back because hlist is used on lots of wikis.

I think we should just get in the cite fix.

Change #1065217 merged by jenkins-bot:

[mediawiki/extensions/Cite@master] Parsoid: Add newline after every reference list item

https://gerrit.wikimedia.org/r/1065217