Page MenuHomePhabricator

Handle Template:Multiple_image in MediaViewer
Closed, ResolvedPublic


The {{multiple image}} template generates HTML code which is intentionally very similar to the HTML code of normal thumbnails, but contains multiple images and possibly multiple captions. The HTML is close enough that MediaViewer picks it up as a thumbnail with a caption, but different enough that it gets confused and misidentifies the caption.

See the talk page of the template for various examples.

Event Timeline

Tgr raised the priority of this task from to Low.
Tgr updated the task description. (Show Details)
Tgr updated the task description. (Show Details)
Tgr set Security to None.
Tgr added a subscriber: Tgr.
In T85354#944695, @Tgr wrote:

Thanks. The task is a bit unclear for me, "fix that" could mean fixing the template or changing how the extension parses that HTML. Can you clarify?

Thanks. The task is a bit unclear for me, "fix that" could mean fixing the template or changing how the extension parses that HTML. Can you clarify?


While the implementation for English Wikipedia could 'just work', there are probably dozens of other wikis that have this template as well, but the HTML generated is totally different. For instance, Polish version of the template uses <div>s instead of <table>s, and the solution that works for enwiki probably just won't work here. So, I'm wondering if it could be done in more semantic manner.

Using <figure> tags (alongside with <figcaption>) seems like a good approach, and it's the most semantic solution, probably. MediaViewer would then work correctly regardless of whether it is English Wikipedia, or Wikimedia wiki at all, as long as the wiki uses these tags. The big problem now is that it would require deep changes all the templates - and I'm quite unsure how often is MediaWiki using new HTML5 tags already.

Parsoid outputs <figure> (see T64594 although I don't know if the HTML snippet there is still up-to-date) for normal thumbnails, not sure about using <figure> from wikitext - it would certainly have the nicest semantics, but it was probably a nontrivial effort to get the template to look right with all skins, so I think adding a few new classes and leaving the existing structure unchanged is a much less painful way. Also, how would you use <figure> for the case of multiple images with a single common caption?

It looks like W3C's HTML reference does not say anything about putting multiple images in one <figure> (it just say 'flow content', which may be almost anything). Some tutorials on the internet, however, actually do it (i.e. place multiple images inside a <figure> with one <figcaption>), so it doesn't seem to be 'bad'.

And of course, I'm not saying the switch to <figure> would be painless. But it's only an idea "for some point in the future...".

The standard requires <figcaption> to be the first or last element, so only one <figcaption> per <figure>. When you have three images with three captions in the same box, you would need three <figure>s. Not an unsolvable problem, but it makes using <figure>s to locate captions awkward. Classes are at least flexible in which element you place them on. (Also, much easier to stick on an existing implementation, especially if it is table-based and the image and caption are different cells.)

Change 182130 had a related patch set uploaded (by M4tx):
More accurate looking for image caption


Change 182130 merged by jenkins-bot:
More accurate looking for image caption