@pmiazga I'm still trying to flesh this card out. Since you understand what I'm doing the most here and hopefully see the value - care to help me flesh out the details?

• Refactor ::newFromContext so this it creates an instance of MobileFormatter. It should not execute any transformations until #format is called.

That's what it does, right?

• For development purposes introduce MwApiMobileFormatter which obtains its HTML from a foreign (or local) mediawiki api. The api should be configurable so we can point to any wiki of our choosing. This will allow us to test MobileFormatter and styles on live Wikipedia articles which will help us debug certain issues as proven by our work in T149852 and T151838
• Make it possible to configure MobileFormatter or MwApiMobileFormatter as the default formatting engine for the wiki.

These two AC conflict with the first line of the description of this task:

Interface should define what is needed to render the mobile (Minerva) skin and should be agnostic of where it comes from.

The MobileFormatter formats HTML. It doesn't retrieve it. That's the responsibility of another collaborator. ExtMobileFrontend::DOMParse should probably end up looking like:

$contentProvider = ContentProvider::newFromContext( $context ); // Generally speaking, I'm in favour of factories but this mirrors the next line...
$formatter = MobileFormatter::newFromContext( $context );

$formattedHtml = $formatter->format( $contentProvider->getContent() );

In T156408#3217464, @phuedx wrote:

• Refactor ::newFromContext so this it creates an instance of MobileFormatter. It should not execute any transformations until #format is called.

That's what it does, right?

It does yup. I just want to ensure we don't actually do any transforming inside it e.g. keep the status quo.
However DOMParse also runs additional setters and getters - maybe they need to be moved into this method? I'm not sure.

With regards to your other comment - I like your thinking with separating ContentProvider. The only thing I'm not sure about is how to unwire our use of DOMParse inside onOutputPageBeforeHTML so that the text it operates on goes via the ContentProvider (which is currently provided by code in core)

Change 349130 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/extensions/MobileFrontend@master] Introduce IContentProvider

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

While most of the work is done on this (according to @pmiazga this is done). Once merged I'll update documentation.

@Jdlrobson Good job!

Change 349130 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] Introduce IContentProvider

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

I'll document and resolve this card today.

Is this Unplanned-Sprint-Work?

Documentation has been added https://www.mediawiki.org/wiki/Extension:MobileFrontend#For_developers.2Fsysadmins