Change Details

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 `mediawiki.skinning.content.parsoid` module is deprecated. [] 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 [] The `content-parser-output` feature should output CSS inside `mediawiki.skinning.content.parsoid` when Parsoid is enabled # Open questions * Is there a PHP function that can be used to reliably check if PHP Parser or Parsoid code is being returned?

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 [x] 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?

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 `mediawiki.skinning.content.parsoid` module is deprecated. [x] 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?