The fact The ResourceLoaderSkinModule ships both parser and parsoid specific styles is continually a source of confusion, but a necessary evil as we look to make Parsoid the default parser everywhere, to ensure they we keep compatibility with the existing parser. We need to consolidate this in the future.
Parsoid specific styles are kept inside a content-media feature and a configuration flag $wgUseNewMediaStructure is used to enable the content-media feature.
A content-thumbnails module provides some styles that relate to both parsoid and the PHP parser
A mediawiki.skinning.content.parsoid module exists, but it does not use ResourceloaderSkinModule or features. This is because several pages, for example, the editor, load this module, and need the styles regardless of whether the skin supports Parsoid or not.
Shipping both Parsoid and PHP Parser styles at the same time would unnecessary bloat page critical CSS where performance matters e.g. Minerva skins
- Goal
- The content-media and content-thumbnails modules are merged. The output of this feature should depend on which parser is being used. Presumably based on $wgUseNewMediaStructure
Descoped
- The mediawiki.skinning.content.parsoid module is deprecated.
- The content-parser-output feature should output CSS inside mediawiki.skinning.content.parsoid when Parsoid is enabled
My understanding is that mediawiki.skinning.content.parsoid cannot be deprecated until Parsoid is the default. Until then things like VisualEditor need it available outside the context of the skin
Open questions
- Is there a PHP function that can be used to reliably check if PHP Parser or Parsoid code is being returned?