Related tickets:

• https://phabricator.wikimedia.org/T347507
• https://phabricator.wikimedia.org/T301080

A draft/first implementation attempt of Parsoid support in PortableInfobox has been started and mostly working in this PR. It's not perfect and still needs some refining, but it mostly works at present. I'm not entirely sure if its the recommended way to do it (with most of the processing being in the wtPostProcess function, however this appears to be the earliest that we can access the parameters passed to the template - I did try to do most of the processing initially in the sourceToDom function, however it does not appear that Parsoid allows us to access the parameters passed to the template until that function has returned, so I relied on grabbing them from the data-mw attribute.

One question that I do have off the back of this is that is there any way to stop Parsoid from wrapping <h2> and <h3>s in section tags? PortableInfobox uses these heading for labels and section headings - it seems that after we pass the HTML back to Parsoid for it to insert into the DOM, it wraps all of the headings in sections. If we can avoid it we do not want this behaviour. For example, under the legacy parser once we finish and pass everything back, we end up with something like (shortened for berevity):

<aside class="portable-infobox noexcerpt searchaux pi-background pi-theme-default pi-layout-default pi-type-Character">
   <h2 class="pi-item pi-item-spacing pi-title" data-source="name">John Appleseed</h2>
   <section class="pi-item pi-group pi-border-color">
   <div class="pi-item pi-data pi-item-spacing pi-border-color" data-source="aliases">
      <h3 class="pi-data-label pi-secondary-font">Aliases</h3>
      <div class="pi-data-value pi-font">
         <ul>
            <li>John Doe</li>
         </ul>
      </div>
   </div>
   <div class="pi-item pi-data pi-item-spacing pi-border-color" data-source="affiliation">
   <h3 class="pi-data-label pi-secondary-font">Affiliation</h3>
</aside>

Under Parsoid, the return is something like the following:

<aside typeof="mw:Extension/infobox mw:Transclusion" about="#mwt1" class="portable-infobox noexcerpt searchaux pi-background pi-theme-default pi-layout-default pi-type-Character" id="mwAw" data-mw="{REMOVED FOR BEREVITY}">
   <section data-mw-section-id="-1" id="mwBA">
      <h2 class="pi-item pi-item-spacing pi-title" data-source="name" id="John_Appleseed">John Appleseed</h2>
      <section class="pi-item pi-group pi-border-color" id="mwCA">
         <div class="pi-item pi-data pi-item-spacing pi-border-color" data-source="aliases" id="mwCQ">
            <section data-mw-section-id="-1" id="mwCg">
               <h3 class="pi-data-label pi-secondary-font" id="Aliases">Aliases</h3>
               <div class="pi-data-value pi-font" id="mwCw">
                  <ul id="mwDA">
                     <li id="mwDQ">John Doe</li>
                  </ul>
               </div>
            </section>
         </div>
         <div class="pi-item pi-data pi-item-spacing pi-border-color" data-source="affiliation" id="mwDg">
            <section data-mw-section-id="-1" id="mwDw">
               <h3 class="pi-data-label pi-secondary-font" id="Affiliation">Affiliation</h3>
</aside>

As you can see, we're getting unnecessary wrapping of the headings in the template which is throwing off the formatting and styling - not a huge deal, but we'd rather avoid that if it is at all possible to tell Parsoid to not wrap these headings. I assume this is being done to let tools like VE know which section of the page the infobox belongs to, as these do not appear in the VisualEditor itself, we get a response which is more in line with what is produced with the legacy parser.

PortableInfobox is still incompatible with Parsoid, and while Original Authority's linked pull request goes a long way, I wanted to make a few notes on issues we encountered on Undertale/Deltarune Wiki when rolling out Parsoid for read views.

• The section wrapping issue is still present in PortableInfobox, and upstream they opted to swap the default to not emit headings at all. On Undertale/Deltarune Wiki, we resorted to ungodly hacks instead. I hope Parsoid will add support for stripping these sections in the future, since they really don't make sense in the context of (all) tag extensions. As far as I can see, VisualEditor is already stripping them.
• Parameters inside <format> and <default> just don't work if the regular <infobox> tag is used. The key issue here is that templates are still expanded using the legacy parser (T301080) and the <infobox> tag is processed after expansion has already finished, so the frame used for parsing the contents of these tags is the top-level frame that does not contain any arguments. The workaround we used for this is swapping <infobox> for {{#tag:infobox}} but...
  1. This means the PortableInfobox XML markup is mixed with the user entered values, which can lead to XML parsing errors.
  2. This means the entire body of PortableInfobox is going to be evaluated, even parts in tags that are never going to get rendered. This isn't a problem until these parts are, for example, adding categories to the page.
• The approach with retrieving arguments from data-mw works only for infoboxes that are 1 level deep. In our template documentation, infobox examples are transcluded through Template:Documentation (and Template:Samples), so they just don't work. The argument values in data-mw are only on mw:Transclusions, which is Template:Documentation in this case.
  • The workaround for this is putting <default>{{{argument}}}</default> on every argument instead of relying on the source parameter on <data>. But at that point, your infobox becomes an ugly mess, so why use PortableInfobox at all?

Can we expect these issues to be addressed before MediaWiki 1.47 releases, which is supposedly (T419048) going to use Parsoid as the default parser?