Last modified: 2014-10-03 14:54:03 UTC
Parsoid must produce/preserve the metadata about additional ResourceLoader modules required by extension tags. (I've heard some gossip that it falls back to PHP parser to do this, so this should be easy to do.) For example, in PHP parser, "<syntaxhighlight lang=php>$foo</syntaxhighlight>" will add up to two modules to ParserOutput's $mModuleStyles: * 'ext.geshi.language.php' (there is such a module for every supported language) * 'ext.geshi.local' (if $wgUseSiteCss is true) This information must somehow be provided by the API used by VisualEditor. The minimum set of things that have to be provided is the ones provided by OutputPage::addParserOutputContent() in PHP, that is modules, module styles, module scripts, module messages and JS config vars. (These are available via the action=parse&prop=modules API in core.)
Ex: http://en.wikipedia.org/w/api.php?action=parse&format=json&page=MathML&prop=modules includes "modulestyles":["ext.rtlcite","ext.math.styles","ext.geshi.language.xml","ext.geshi.local","ext.geshi.language.html5"] CSS modules for inclusion in the <head> would be a good start and will help reduce rendering diffs.
Change 160423 had a related patch set uploaded by Marcoil: WIP: Bug 67540 - Load extension CSS modules https://gerrit.wikimedia.org/r/160423
There's a WIP patch now at https://gerrit.wikimedia.org/r/160423 that adds the extensions' CSS modules to the style link. If we also want to load further extension resources, like JS or messages, I suppose we'll have to add loading ResourceLoader's client first and let it load everything else. Is this the way we should go?
I think we'll want the lowlevel information about the modules available (via data-mw?), in addition to having One True Resource Loader URL which will load them all. In particular two of OCG backends, the ZIM writer and the future parsoid-phantomjs-PDF backend, will want to download the set of resources used by a (potentially large) set of pages. We don't want to have to download the same resources in slight variations over and over again. If there are N different resources used on a wiki, there are 2^N different resource loader URLs which load various combinations of the N resources. We'd rather just load the N resources once, even if that means we have to do a little extra work ourselves to order and merge them.
(12:15:15 PM) gwicke: cscott: we should expose the list separately, but for browsers it's probably more efficient to still do some bundling (12:15:29 PM) gwicke: good to unbundle the per-page modules from the global ones though (12:15:35 PM) gwicke: right now those are all mixed afaik (12:18:03 PM) cscott-free: gwicke: agreed. i'm thinking of exposing the list via data-mw (for example) while still providing the resource url in a <link> tag for browsers.
As discussed on IRC, we'll do a first patch only for CSS support, and then expand on it with the rest of extensions' resources. We can continue using this bug for this and for C. Scott's proposal of exposing the modules in metadata. Btw, does anyone have examples of pages where an extension CSS causes Parsoid to render differently from PHP? I'd like to test the visual diffs with this patch. Thanks!
Change 160423 merged by jenkins-bot: Bug 67540 - Load extension CSS modules https://gerrit.wikimedia.org/r/160423
The merged patch takes care of adding the appropriate CSS modules to the load list, but only for extensions. Some parser functions (e.g. Babel) also have CSS modules, there's a patch for MW that would allow Parsoid to know about them here: https://gerrit.wikimedia.org/r/162123
