Last modified: 2013-12-13 20:22:36 UTC
Created attachment 12721 [details] Screenshot comparing MW (PHP Parser) dom to VE dom The image is displayed too small, not due to CSS but due to the width/height attributes explicitly being incorrectly set. No idea where its getting these values from. Strangely enough, when editing the template with the template dialog, making no changes, and clicking "Apply changes" (causing a re-rendering) it shows up correctly (though that's likely because we're getting that from the php parser api).
That suggests Parsoid is giving us HTML with the wrong image dimensions. Possibly because of the intricate web of preference and configuration logic that determines the thumb size in production.
The template in question uses {{#invoke:InfoboxImage}} and a bunch of ludicrously-complex wikitext, but when not given a size will use the standard thumbnail size, which enwiki uses on default MW options - i.e. 220px wide. Instead, Parsoid comes up with the size of 128x180px, though from where I can't quite see.
180px happens to be the default size (index 2 in $wgThumbLimits). We *could* add the default thumb size setting in the MediaWiki API, but afaik right now that information is not available. As documented in http://www.mediawiki.org/wiki/Parsoid/MediaWiki_DOM_spec#Images, we set the mw-default-size class on images that should be scaled to preferences. User-specific scaling can then done with client-side JS by matching on the class. That avoids the need for different versions of the page content in caches, which is good for performance.
I think this should be reassigned to VE? It seems like VE should be observing the mw-default-size class when it displays the image.
We are moving closer to using Parsoid HTML for page views and would like it to represent the content anonymous users actually see. Additionally, clients like VE currently don't implement default thumbnail size handling, which leads to extra requests for smaller thumbnails when switching to edit view. For these reasons I believe that it makes sense for us to track the currently configured default size in Mediawiki. As mentioned in comment #3, this means that we'll have to 1) expose the currently configured default thumb size in the MediaWiki API, and 2) use it instead of the MediaWiki default size.
As an easy temporary hack, we can also change the Parsoid default to match the Wikipedia default rather than the MediaWiki default.
Change 100393 had a related patch set uploaded by GWicke: Bug 50523: Hard-code Wikipedia rather than MW defaults https://gerrit.wikimedia.org/r/100393
Change 100393 merged by jenkins-bot: Bug 50523: Hard-code Wikipedia rather than MW defaults https://gerrit.wikimedia.org/r/100393
Change 101286 had a related patch set uploaded by GWicke: Merge "Bug 50523: Hard-code Wikipedia rather than MW defaults" https://gerrit.wikimedia.org/r/101286
Change 101347 had a related patch set uploaded by GWicke: Bug 50523: Hard-code Wikipedia rather than MW defaults https://gerrit.wikimedia.org/r/101347
Change 101286 merged by GWicke: Merge "Bug 50523: Hard-code Wikipedia rather than MW defaults" https://gerrit.wikimedia.org/r/101286
Change 101347 merged by GWicke: Bug 50523: Hard-code Wikipedia rather than MW defaults https://gerrit.wikimedia.org/r/101347
