Looks like Parsoid is marking up the first paragraph as part of the transclusion. This might be a bug in Parsoid or broken syntax in the infobox template (e.g. unclosed HTML tags).

It happens with some infoboxes but not with others. Does this suggest that the problem is in the templates?

I just remembered about T178970. Relevant?

I experimented a bit and I think I found the reason this issue: the template "Infobox Bande dessinée" outputs <nowiki /> at the end, coming from the sub-template "Infobox/Titre en italique" (or its sub-sub-template "Titre en italique"). Parsoid treats it as part of the first paragraph of the article, and then marks the entire paragraph as being "affected by a template" and thus not separately editable.

The <nowiki /> was added deliberately to prevent the PHP parser from rendering an empty paragraph after the infobox (due to the newlines between transclusions of sub-templates): https://fr.wikipedia.org/w/index.php?title=Modèle%3AInfobox%2FTitre_en_italique&diff=prev&oldid=142843034

I am not sure if Parsoid could handle this in a better way. It's an awkward behavior, but it seems to make sense with how paragraph generation works (just imagine that instead of <nowiki />, the template had foo there: it would become a part of the first paragraph of the page).

To work around the issue on French Wikipedia, you'd have to do the following:

• Remove the <nowiki /> at the end of templates like "Infobox/Titre en italique", "Titre en italique", and any others, to prevent infoboxes using them from being glued to first paragraph in VE
• Remove the newline between {{Infobox/Fin}} and {{Infobox/Titre en italique|...}} in "Infobox Bande dessinée" and any other infobox using those templates, to prevent an empty paragraph from appearing after the infobox

Here's a minimal page where you can reproduce the problem: https://test.wikipedia.org/wiki/T194945a

{{1x|
<div>a</div>
<nowiki />}}
b

Identical page without the <nowiki /> works fine: https://test.wikipedia.org/wiki/T194945b

{{1x|
<div>a</div>
}}
b

Though it's quite clear these <nowiki /> are tricky, I'd say the issue discussed here is rather in the visual editor, which should properly handle the case.

In T194945#4392162, @Od1n wrote:

Though it's quite clear these <nowiki /> are tricky, I'd say the issue discussed here is rather in the visual editor, which should properly handle the case.

Yes and no. The visual editor could definitely handle this edge case better, but using <nowiki /> tags like this is somewhat hacky and was fairly likely to cause strange behaviour somewhere else.

So, there's shared responsibility here. The easiest thing to do would be to follow matmarex's steps to fix the problem. Digging into the VisualEditor-Parsoid stack to fix this problem would likely be much harder and more time consuming.

The output HTML are two properly distinct elements, a div followed by a p, and the p is clearly outside of the template transclusion. Thus I maintain the issue is at the visual editor level.

The difficulty of the fix should be asked to a parsoid developer. If the fix would be too difficult, editing the templates and the pages as suggested above shouldn't be considered as a fix but as a workaround.

As a note of hope, this issue would probably be fixed by T114445.

In T194945#4393951, @Od1n wrote:

The output HTML are two properly distinct elements, a div followed by a p, and the p is clearly outside of the template transclusion. Thus I maintain the issue is at the visual editor level.

The difficulty of the fix should be asked to a parsoid developer. If the fix would be too difficult, editing the templates and the pages as suggested above shouldn't be considered as a fix but as a workaround.

As a note of hope, this issue would probably be fixed by T114445.

Note that Parsoid doesn't strip elements in the input unlike the PHP parser. Parsoid has to handle input a lot more strictly so that when edited output is serialized to wikitext, we don't introduce dirty diffs.

More specifically, in this case, Parsoid won't strip the <nowiki /> tag (unlike the PHP parser). So, this means that the <nowiki/> tag kicks off a new paragraph and it comes from the template.

While we could tweak some of Parsoid's template handling code (for example, by selectively stripping some trailing elements from template output), we have to be careful to not introduce other edge cases.

Talking of workarounds, note that editors added a <nowiki/> to workaround the PHP parser's handling. @matmarex has provided a solution that eliminates that workaround in a way that doesn't need special handling in Parsoid. As noted above, to handle cases like this, we would have to add additional conditional code which breaks the current uniform handling.

So, the cleanest solution that eliminates special cases and workarounds would be the one suggested by @matmarex and hope you consider that.

This makes sense. I am just uncomfortable with removing the "nowiki" from the sub (and main) template {{Titre en italique}}. That one "nowiki" fixes many cases of empty <p>.

How about using a bot to move {{Infobox/Titre en italique}} bricks into the infoboxes, i.e. above the closing brick {{Modèle:Infobox/Fin}}? Then documenting this so that editors don't reintroduce back the issue.

How about using a bot to move {{Infobox/Titre en italique}} bricks into the infoboxes, i.e. above the closing brick {{Modèle:Infobox/Fin}}? Then documenting this so that editors don't reintroduce back the issue.

I've just tried this, and it doesn't fix the issue…

(just imagine that instead of <nowiki />, the template had foo there: it would become a part of the first paragraph of the page).

Excellent example, I was going to raise that case myself. It's a pretty simple and obvious thing we might do at any time. We expect (and need) to be able to edit the plaintext after the template. Any editor that can't edit plaintext is clearly broken, regardless of explanations for why it is broken.

The problem is that plaintext is being marked as non editable, instead of having the non editable zone terminate at the end of template output.

VE has a lot of weird and very hard to fix bugs, and they're almost all consequences of a single original architecture error. VE should have been designed as a visual-editor-for-wikitext, instead VE was build with no ability to edit wikitext at all (it's an HTML editor). The big and difficult issues with VE (and community rejection of VE) largely trace back to the crazy complex Parsoid translation hack. The real fix for all these issues would be a genuine visual-editor-for-wikitext.