Still to-do:

• implement getters and setters for innerHTML and outerHTML using Remex.
• implement DOM Parsing & serialization interfaces from IDLeDOM 0.5.0
• implement PHP-specific Document::{load,loadXML,saveHTML,saveXML} methods (also defined in IDLeDOM 0.5.0)

Implemented in 2621a6a930c813f863ff304142be85c725f7b617 and related patches, although there may be bugs & performance work remaining (which will be opened as separate tasks).

Implemented in c3b9eb120e8a18b7f0da25e7235bc4ef87bb726a (and a number of preceding patches to IDLeDOM etc).

In theory we should have invalidated our cache when the image was updated. So that's probably still a Parsoid-core integration bug we need to track down and fix, probably. Or else it will magically Just Work when we move from RestBASE to ParserCache.

Further, it looks like this works on the command line:

$ php bin/parse.php --domain en.wikipedia.org --pageName Wikipedia:Wikipedia_for_Schools/Welcome/Mathematics --normalize=parsoid < /dev/null | fgrep versicolor
<div class="thumb"><span typeof="mw:Image"><a href="./File:Fisher_iris_versicolor_sepalwidth.png"><img resource="./File:Fisher_iris_versicolor_sepalwidth.png" src="//upload.wikimedia.org/wikipedia/commons/thumb/1/1d/Fisher_iris_versicolor_sepalwidth.png/270px-Fisher_iris_versicolor_sepalwidth.png" data-file-width="957" data-file-height="638" data-file-type="bitmap" height="120" width="180" srcset="//upload.wikimedia.org/wikipedia/commons/thumb/1/1d/Fisher_iris_versicolor_sepalwidth.png/405px-Fisher_iris_versicolor_sepalwidth.png 1.5x, //upload.wikimedia.org/wikipedia/commons/thumb/1/1d/Fisher_iris_versicolor_sepalwidth.png/540px-Fisher_iris_versicolor_sepalwidth.png 2x"/></a></span></div>

So this might be a misconfiguration (somehow) in how the rest_v1 endpoint is set up?

Discussed in meeting today. This makes sense. *Ideally* there would be a way to pop up the toolbar (a small "expand" icon or something like that?) for those cases where there is rich text present, but as @dchan points out, best practice is really *not* to include rich text here. My recollection is that the common case that shows up in rules ends up being either simple boldface or italics markup (which really belongs outside the -{ ... }- markup but sometimes ends up inside) or else <span> tags -- in the latter case the intended usage is something like a gloss "xyz in traditional (pdq in simplified characters)" where the <span> is used to format the gloss. But most cases this will be done with a template anyway.

This is the instantcommons fallback, since the image is not present on enwiki it should be grabbed from commons. I was pretty certain that instantcommons works in Parsoid, I wonder what's going on. @Arlolra any ideas?

So, if I understand correctly, current status is that CI is running composer test-some <paths> now, but we haven't patched core's composer.json so that composer test Just Works like we expect. But it should be safe to do that now because CI doesn't use composer test any more?

core doesn't have the . in the command... see https://gerrit.wikimedia.org/r/c/mediawiki/core/+/441412 and T199403: `composer test` in MediaWiki core doesn't work like it does in other repositories, etc...

Unusually, I think we committed this zero-conf code only on the release branch, not in master, right? So we don't have to revert it in master to avoid breaking things the next time we muck around in MWParsoid/Config.

Parsoid v0.13.0 has been tagged, since I have not heard wailing and gnashing of teeth.

Done, in the wikimedia/idle-dom package, which defines the interfaces necessary for a DOM implementation:
https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/libs/IDLeDOM/+/refs/heads/main/WebIDL.md