Page MenuHomePhabricator

Use figure and figcaption HTML5 elements when possible
Open, MediumPublic

Description

Since MediaWiki allows images that are clearly separated out, we should see if we can use <figure> and <figcaption>. These tags are intended for "some flow content, optionally with a caption, that is self-contained and is typically referenced as a single unit from the main flow of the document."

This would particularly make sense for thumb and frame where a caption is already shown. However, figure can also be used without figcaption, which should simplify implementation.

The main concern is backwards-compatibility with browsers that don't know about these tags. They're new to HTML5 (which is now always on in MediaWiki), but

  1. Older IE will not be able to style these elements from CSS
  2. Older IE will not be able to select these elements from JavaScript. This can be worked around by calling createElement(tagName) once for each of the relevant tag names.

For issue number 2, I think jQuery's internal createSafeFragment already takes care of old IE. So only the styling issue remains.


See also: T25932: Allow use of semantic HTML5 elements in wikitext

Details

Reference
bz49097
ProjectBranchLines +/-Subject
mediawiki/coremaster+4 K -70
mediawiki/coremaster+25 -37
mediawiki/coreREL1_37+9 -2
mediawiki/coremaster+9 -2
operations/mediawiki-configmaster+12 -1
mediawiki/corewmf/1.38.0-wmf.2+15 -2
mediawiki/corewmf/1.38.0-wmf.3+15 -2
mediawiki/coremaster+15 -2
operations/mediawiki-configmaster+3 -3
mediawiki/coreREL1_35+3 -13
mediawiki/coreREL1_36+3 -13
mediawiki/coremaster+3 -13
operations/mediawiki-configmaster+2 -0
operations/mediawiki-configmaster+6 -0
mediawiki/coremaster+1 -1
mediawiki/coremaster+235 -212
mediawiki/coremaster+535 -229
mediawiki/coremaster+7 -0
mediawiki/coremaster+134 -141
mediawiki/coremaster+1 -0
mediawiki/extensions/VectorBetamaster+1 -1
Show related patches Customize query in gerrit

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

From an accessibility standpoint, there may be reasons to emit a descriptive <figcaption> even if it is not visible to a sighted user.

That said, my understanding was that we couldn't actually do that because the figcaption could contain (eg) <p> tags that would break rendering in an inline context (where captions are normally hidden) and so we don't/can't actually emit the figcaption unless it is visible. But @Arlolra seems to have found the exception to that rule which we've all forgotten; I await with bated breath.

And (at the risk of continuing @ssastry's drift off-topic), in addition to fragmentation issues, improving the functionality of client-side gadgets is one reason to avoid unnecessary read-view transformations. (Ultimately, fast editing is also benefited if VE can operate with the rendered content instead of having to reload content at editor startup. The idea is that VE only needs to load the (fairly small) data-mw associated w/ the region being edited at startup.)

But @Arlolra seems to have found the exception to that rule which we've all forgotten; I await with bated breath.

My confusion was that mw:Image(/Frameless) aren't always inline, for example if they have explicit options like |right. In which case, we'd emit a figure but hide the caption to match the output from the legacy parser.

Change 647318 had a related patch set uploaded (by Arlolra; owner: Arlolra):
[mediawiki/core@master] Update tests for $wgUseNewMediaStructure

https://gerrit.wikimedia.org/r/647318

Change 647318 abandoned by Arlolra:
[mediawiki/core@master] Update tests for $wgParserOutputLegacyMediaDOM

Reason:
These are now in I978187f9f6e9e0a105521ab3e26821e36a96b911

https://gerrit.wikimedia.org/r/647318

Arlolra claimed this task.

Change 701449 had a related patch set uploaded (by Arlolra; author: Arlolra):

[mediawiki/core@master] Add <figure> to the never suppressing group in BlockLevelPass

https://gerrit.wikimedia.org/r/701449

Change 701449 merged by jenkins-bot:

[mediawiki/core@master] Add <figure> to the never suppressing group in BlockLevelPass

https://gerrit.wikimedia.org/r/701449

Change 507512 merged by jenkins-bot:

[mediawiki/core@master] Emit media structure as piloted in Parsoid

https://gerrit.wikimedia.org/r/507512

Change 701612 had a related patch set uploaded (by Arlolra; author: Arlolra):

[operations/mediawiki-config@master] Disable legacy media structure on test wikis

https://gerrit.wikimedia.org/r/701612

Change 701612 merged by jenkins-bot:

[operations/mediawiki-config@master] Enable Parsoid inspired media structure on test wikis

https://gerrit.wikimedia.org/r/701612

Mentioned in SAL (#wikimedia-operations) [2021-06-28T23:05:39Z] <urbanecm@deploy1002> Synchronized wmf-config/InitialiseSettings.php: 5ec855d14b31a9392274c2bfe2e21e2ad44986bc: Enable Parsoid inspired media structure on test wikis (T51097) (duration: 00m 59s)

With the train going out to group 0 today, we can look at two wikis which should be configured differently based on T51097#7182465,

I verified that this is indeed running on testwiki. For example, after an ?action=purge on https://test.wikipedia.org/wiki/Rusa_test_page_2 I see,

<figure class="mw-halign-right" typeof="mw:Image/Thumb"><a href="/wiki/File:Onion_diagram.svg"><img alt="" src="//upload.wikimedia.org/wikipedia/commons/thumb/e/e1/Onion_diagram.svg/300px-Onion_diagram.svg.png" decoding="async" width="300" height="197" srcset="//upload.wikimedia.org/wikipedia/commons/thumb/e/e1/Onion_diagram.svg/450px-Onion_diagram.svg.png 1.5x, //upload.wikimedia.org/wikipedia/commons/thumb/e/e1/Onion_diagram.svg/600px-Onion_diagram.svg.png 2x" data-file-width="875" data-file-height="575"></a><figcaption>In this example onion, we test image placement.</figcaption></figure>

However, on mediawikiwiki, after similarly purging we get on https://www.mediawiki.org/wiki/Parsoid

<div class="thumb tright"><div class="thumbinner" style="width:514px;"><a href="/wiki/File:Parsoid_HTML-RDFa_content_model.svg" class="image"><img alt="" src="//upload.wikimedia.org/wikipedia/commons/thumb/2/2e/Parsoid_HTML-RDFa_content_model.svg/512px-Parsoid_HTML-RDFa_content_model.svg.png" decoding="async" width="512" height="362" class="thumbimage" data-file-width="512" data-file-height="362"></a>  <div class="thumbcaption">Artist's impression of the Parsoid HTML5 + RDFa wiki runtime</div></div></div>

I've noticed an important different between the two formats and it relates to where the emitted class is located. Before this class was applied directly to the img object, but now it seems this is on the wrapping class. While this is probably a rare use case, it's an important change and I know at least some image headers on mediawiki.org etc which likely will have to be adapted to take this into account.

[[File:Onion diagram.svg|thumb|right|300px|In this example onion, we test image placement.|class=djtest]]
<figure class="mw-halign-right djtest" typeof="mw:Image/Thumb"><a href="/wiki/File:Onion_diagram.svg" title=""><img alt="" src="//upload.wikimedia.org/wikipedia/commons/thumb/e/e1/Onion_diagram.svg/300px-Onion_diagram.svg.png" decoding="async" width="300" height="197" srcset="//upload.wikimedia.org/wikipedia/commons/thumb/e/e1/Onion_diagram.svg/450px-Onion_diagram.svg.png 1.5x, //upload.wikimedia.org/wikipedia/commons/thumb/e/e1/Onion_diagram.svg/600px-Onion_diagram.svg.png 2x" data-file-width="875" data-file-height="575"></a><figcaption>In this example onion, we test image placement.</figcaption></figure>
<div class="thumb tright"><div class="thumbinner" style="width:302px;"><a href="/wiki/File:Onion_diagram.svg" class="image" title=""><img alt="" src="//upload.wikimedia.org/wikipedia/commons/thumb/e/e1/Onion_diagram.svg/300px-Onion_diagram.svg.png" decoding="async" width="300" height="197" class="djtest thumbimage" srcset="//upload.wikimedia.org/wikipedia/commons/thumb/e/e1/Onion_diagram.svg/450px-Onion_diagram.svg.png 1.5x, //upload.wikimedia.org/wikipedia/commons/thumb/e/e1/Onion_diagram.svg/600px-Onion_diagram.svg.png 2x" data-file-width="875" data-file-height="575"></a>  <div class="thumbcaption"><div class="magnify"><a href="/wiki/File:Onion_diagram.svg" class="internal" title="Enlarge"></a></div>In this example onion, we test image placement.</div></div></div>

Also the following features broken alignment:

As well and most importantly and I think a blocker: printing in Vector is not aligning correctly.

And I see a CSS reflow for videos on test.wikipedia.org. This is specifically with the videojs player, which is active on test.wp.org, not sure about the old Kaltura player.
https://test.wikipedia.org/wiki/User:TheDJ/sandbox

@TheDJ thanks for filing those issue. I've created or updated tasks where they can be discussed individually.

Change 714635 had a related patch set uploaded (by Arlolra; author: Arlolra):

[operations/mediawiki-config@master] Disable legacy media dom on a few more wikis

https://gerrit.wikimedia.org/r/714635

Change 714635 merged by jenkins-bot:

[operations/mediawiki-config@master] Disable legacy media dom on a few more wikis

https://gerrit.wikimedia.org/r/714635

Mentioned in SAL (#wikimedia-operations) [2021-08-25T18:16:22Z] <urbanecm@deploy1002> Synchronized wmf-config/InitialiseSettings.php: e6df0803e4eaca91bd725bcd376b260b97917de3: Disable legacy media dom on a few more wikis (T51097) (duration: 01m 05s)

ok... now thumbframes on mediawiki.org are loading late.. seems like the parsoid CSS module is not added with addModuleStyles() to ensure its loaded before the page rendering starts ?

See the image on https://www.mediawiki.org/wiki/MediaWiki jump from center to right as the page loads.
Similar on https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2021

@TheDJ Thanks for reporting

It looks like the issue is with the cached stylesheet

https://www.mediawiki.org/w/load.php?lang=en&modules=ext.discussionTools.init.styles%7Cext.echo.styles.badge%7Cext.uls.pt%7Cext.visualEditor.desktopArticleTarget.noscript%7Cext.wikimediaBadges%7Cmediawiki.ui.button%2Cicon%7Coojs-ui.styles.icons-alerts%7Cskins.vector.icons%2Cstyles&only=styles&skin=vector

If I add ?debug=true to it, I get results for "mw:Image"

The jump is probably because until the cache is purged, the styles don't kick in until VE or whathaveyou's styles are fetched by JS.

Let me see about busting the cache

I also see all the VE JS being loaded (with debug=true).. that's not normal....

I could be wildly off base about caching ... suffice it to say, I'm looking into it

When I load https://www.mediawiki.org/wiki/MediaWiki with JS disabled the image says on the left, which confirms @TheDJ's theory that the correct CSS is being loaded by JS (addModules) rather than properly with addModuleStyles. However, I couldn't reproduce this on https://test.wikipedia.org/wiki/Image?useskin=vector&useskinversion=1 - not sure what's different really.

As to why it's happening...I have no idea. My guess is that this is another regression from the skin refactoring, T287410: ResourceLoaderSkinModule: Skins should not use the legacy styling feature which recently touched stuff like https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/skins/Vector/+/a50b1db7931610a038197b74ba798fe307e9055e

Also for some reason Timeless has the "content-media" feature set to false, so it's just fully broken there AFAICT.

Correcting my previous comment, VisualEditor will load the styles via JS if you have it enabled, so you actually need to turn that off, and then you'll find that the photo no longer jumps and stays on the (wrong) left side, even with JS enabled. So the real problem is that the skin is not loading these styles.

OK, I think this is related to caching (yes, @Arlolra was right). Specifically, the styles for this are loaded in an override of ResourceLoaderSkinModule::getStyleFiles():

				if ( $feature === 'content-media' && !$this->getConfig()->get( 'ParserEnableLegacyMediaDOM' ) ) {
					$featureFilePaths['screen'][] = new ResourceLoaderFilePath(
						'resources/src/mediawiki.skinning/content.media.less',
						$defaultLocalBasePath,
						$defaultRemoteBasePath
					);
				}

However, this new file path is not seen by ResourceLoaderModule::getDefinitionSummary() because it checks $this->styles. When $wgParserEnableLegacyMediaDOM was flipped, there was no cache invalidation since according to RL, the module and all its files were the same.

Quick fix: Add value of $wgParserEnableLegacyMediaDOM to ResourceLoaderSkinModule::getDefinitionSummary()

I only did a quick skim, but it wasn't clear to me how the other feature changes experienced cache invalidation. Maybe a more detailed audit is necessary.

Change 714841 had a related patch set uploaded (by Arlolra; author: Arlolra):

[mediawiki/core@master] Alter the skin definition summary based on wgParserEnableLegacyMediaDOM

https://gerrit.wikimedia.org/r/714841

Change 714841 merged by jenkins-bot:

[mediawiki/core@master] resourceloader: Call getStyleFiles from FileModule::getFileHashes

https://gerrit.wikimedia.org/r/714841

Change 719179 had a related patch set uploaded (by Krinkle; author: Arlolra):

[mediawiki/core@REL1_36] resourceloader: Call getStyleFiles from FileModule::getFileHashes

https://gerrit.wikimedia.org/r/719179

Change 719180 had a related patch set uploaded (by Krinkle; author: Arlolra):

[mediawiki/core@REL1_35] resourceloader: Call getStyleFiles from FileModule::getFileHashes

https://gerrit.wikimedia.org/r/719180

Change 719180 merged by jenkins-bot:

[mediawiki/core@REL1_35] resourceloader: Call getStyleFiles from FileModule::getFileHashes

https://gerrit.wikimedia.org/r/719180

Change 719179 merged by jenkins-bot:

[mediawiki/core@REL1_36] resourceloader: Call getStyleFiles from FileModule::getFileHashes

https://gerrit.wikimedia.org/r/719179

Shouldn't these changes have rolled out by now ? If so, why is the thumbnail on MediaWiki.org still jumping around after load ? (Ah, because I use Timeless and there is T287965: Skins not loading content-media feature misaligned? )

Change 724861 had a related patch set uploaded (by Arlolra; author: Arlolra):

[operations/mediawiki-config@master] Disable legacy media dom on a few more wikis

https://gerrit.wikimedia.org/r/724861

Change 724861 merged by jenkins-bot:

[operations/mediawiki-config@master] Disable legacy media dom on a few more wikis

https://gerrit.wikimedia.org/r/724861

Mentioned in SAL (#wikimedia-operations) [2021-09-30T18:20:53Z] <thcipriani@deploy1002> Synchronized wmf-config/InitialiseSettings.php: Config: [[gerrit:724861|Disable legacy media dom on a few more wikis (T51097)]] (duration: 01m 08s)

Change 725160 had a related patch set uploaded (by Arlolra; author: Arlolra):

[mediawiki/core@master] Add $wgParserEnableLegacyMediaDOM to REL1-37 release notes

https://gerrit.wikimedia.org/r/725160

Deployment to Meta broke global user pages appearing on wikis that still use the legacy <div>-based output, see T292498. Without any countermeasures, I’m pretty sure the same will happen on file description pages if Commons switches before other wikis.

Without any countermeasures, I’m pretty sure the same will happen on file description pages if Commons switches before other wikis

Thanks. If you can think of any other situation where there is similar cross wiki inclusion, please let me know

Change 726643 had a related patch set uploaded (by Arlolra; author: Arlolra):

[operations/mediawiki-config@master] [WIP] Enable legacy media dom on metawiki

https://gerrit.wikimedia.org/r/726643

Change 726645 had a related patch set uploaded (by Arlolra; author: Arlolra):

[mediawiki/core@master] [WIP] Always ship content.media.less when content-media feature is requested

https://gerrit.wikimedia.org/r/726645

I generally agree with the direction of the patch, if we can load the styles regardless of what the config flag is, we should.

However, the situation for Commons is more tricky, because it's arbitrary MediaWiki installations requesting those pages...ideally we'd backport the styles for 1.35/1.36 if they're not there already. How bad will it look if those styles aren't there?

Change 726697 had a related patch set uploaded (by Arlolra; author: Arlolra):

[mediawiki/core@master] Add a separate config for content.media.less

https://gerrit.wikimedia.org/r/726697

Change 726707 had a related patch set uploaded (by Arlolra; author: Arlolra):

[mediawiki/core@wmf/1.38.0-wmf.2] Add a separate config for content.media.less

https://gerrit.wikimedia.org/r/726707

Change 726709 had a related patch set uploaded (by Arlolra; author: Arlolra):

[mediawiki/core@wmf/1.38.0-wmf.3] Add a separate config for content.media.less

https://gerrit.wikimedia.org/r/726709

Change 726697 merged by jenkins-bot:

[mediawiki/core@master] Add a separate config for content.media.less

https://gerrit.wikimedia.org/r/726697

Change 726709 merged by jenkins-bot:

[mediawiki/core@wmf/1.38.0-wmf.3] Add a separate config for content.media.less

https://gerrit.wikimedia.org/r/726709

Change 726707 merged by jenkins-bot:

[mediawiki/core@wmf/1.38.0-wmf.2] Add a separate config for content.media.less

https://gerrit.wikimedia.org/r/726707

Change 726643 merged by jenkins-bot:

[operations/mediawiki-config@master] Enable legacy media dom on metawiki

https://gerrit.wikimedia.org/r/726643

If you can think of any other situation where there is similar cross wiki inclusion, please let me know

Probably MediaWiki-extensions-DoubleWiki as well (used on Wikisources and a few other wikis). The transcluded pages often depend on their own wiki’s sitewide CSS and are thus already broken, breaking them a bit more doesn’t worsen the situation a lot…

How bad will it look if those styles aren't there?

Hopefully not that bad, at least in average. Images on Commons file description pages are usually inline (often transcluded in table cells), which don’t require much CSS. If you want to make sure, the necessary styles can be copied to (or @imported from) MediaWiki:Filepage.css, which should be loaded on third-party wikis as well.

How bad will it look if those styles aren't there?

Hopefully not that bad, at least in average. Images on Commons file description pages are usually inline (often transcluded in table cells), which don’t require much CSS. If you want to make sure, the necessary styles can be copied to (or @imported from) MediaWiki:Filepage.css, which should be loaded on third-party wikis as well.

That was the same conclusion that Arlo and I came to. I suggested that we make sure to backport the correct styles for the 1.35/1.36/1.37 branches, but not wait for a release before flipping the switch on Commons. If it turns out to be much worse than expected, we can ask Reedy to put out a MW maintenance release outside the normal cycle for this change.

Change 730735 had a related patch set uploaded (by C. Scott Ananian; author: Arlolra):

[mediawiki/core@REL1_37] Add $wgParserEnableLegacyMediaDOM to REL1-37 release notes

https://gerrit.wikimedia.org/r/730735

Change 725160 merged by jenkins-bot:

[mediawiki/core@master] Add $wgParserEnableLegacyMediaDOM to REL1-37 release notes

https://gerrit.wikimedia.org/r/725160

Change 730735 merged by C. Scott Ananian:

[mediawiki/core@REL1_37] RELEASE-NOTES-1.37: Add note about $wgParserEnableLegacyMediaDOM

https://gerrit.wikimedia.org/r/730735

Change 726645 abandoned by Arlolra:

[mediawiki/core@master] [WIP] Always ship content.media.less when content-media feature is requested

Reason:

https://gerrit.wikimedia.org/r/726645