@Krinkle May I kindly ask if you have news about this?

You can test the mobile version on a desktop computer simply by using the fr.m.wikipedia.org domain. Although not on a smartphone, it's sufficient when writing local CSS etc.

Uploaded a new patch:

Here is the CSS I'm adding in the patch:

.mw-special-Mostlinkedtemplates .mw-redirect {
    font-style: italic;
}

A few notes:

• I'm precisely targetting Special:Mostlinkedtemplates (for now), but maybe we want to italicise redirects on other pages as well.
• Notice this CSS is loaded on all special pages (see rMW15eac4c27939).

Redirects should be italicised on this special page as well: Special:MostTranscludedPages.

It is registered as a different module

Understood. It loads vector.js (from the legacy skin) in addition to the rest.

Thanks @Func for looking into this.

Indeed, I was also encountering this issue on mediawiki.org. I don't remember on what pages exactly, but I'm pretty sure it was occurring on ResourceLoader/Core modules.

Also, I usually fix this issue by doing a force refresh (shift + F5). A regular refresh (F5) isn't sufficient.

I am also encountering this issue. Nowadays it seems less frequent, but it may still happen sometimes. (edit: a fix has just been deployed, it simply hasn't reached frwiki yet)

I just noticed the .mw-first-heading is missing here:
https://gerrit.wikimedia.org/g/mediawiki/skins/Vector/+/475508647466ea1c67d3e0d378ca3b4a76668e84/stories/skin.stories.data.js#91

Following up to gerrit 737112 from late 2021 which has these FIXME:

Currently all skins have #firstHeading, .firstHeading and .mw-first-heading, the only exception being cologneblue which only has #firstHeading.

1. Back in 2009, class .firstHeading had been replaced with an ID #firstHeading, see T17427 and https://phabricator.wikimedia.org/rMWc68f345d54c3
2. Very soon after, the class .firstHeading has been restored, alongside the ID, for backward compatibility, see https://phabricator.wikimedia.org/rMWba0f7c4c1378
3. In 2014, the ID has been considered obsolete, see https://phabricator.wikimedia.org/rMW7d244175a3bd359bd and also this documentation update.
4. The present ticket introduced a new class .mw-first-heading for name standardization.

Currently the font has a pixel-based size (gerrit 593629).

Here is an extract of the markup in History and User contributions pages:

Has been fixed on Gerrit (relevant occurrences of class replaced with link-class).

Tests currently fail because user-links-collapsible-item is added to the <li>, and mw-ui-icon mw-ui-icon-before are added to the inner <a>,
but the tests look at the same place for both sets of classes: $content['user-menu']['userpage']['class'].

Some people may prefer to keep this additional item in the dropdown menu:

• Has a text description.
• The "Contributions" link is next to it.

I hadn't understand AC4 is only about the HTML markup, not at all about the displayed element.

About the (conflicting) AC2 and AC4, currently the entry is always present in the dropdown menu, including on large windows when there is also the direct icon.

In T289619#7638516, @Huji wrote:

I saw this in production on fawiki, so I deleted the Gadget I had created which would bring the Watchlist icon back out of the user dropdown menu. Unsure if other wikis had copied my Gadget too; if yes, they should delete as well.

@Jdlrobson The below code (found here) seems to be incorrect:

Is the above workaround still needed?

Now that by default, and automatically, all gadgets get type "general", except CSS-only (and without dependencies) gadgets which get type "styles",

Refs the local fix: 190070230, which I followed with 190082211.

The message has been implemented in Modern: https://github.com/wikimedia/mediawiki-skins-Modern/commit/35c9337d207714c75716bfb5f1b6ca11c4d2f5fb.

Just to be clear, I tested and gave as examples the Monobook and Modern skins, but it was out of habit:

For the heading to be effectively hidden (or replaced with a customized text), the message has to be implemented in the skin. It is currently the case for example with Vector, but still not with Monobook or Modern.

Refs T216318, where I had submitted a patch (see changeset 6) to implement width and height attributes, with a sidecar file for faster subsequent retrievals of their values.

Merge conflict with this large change. I'm not planning to rebase my patch…

Wow, that's quite tricky this need to keep references to manipulate when the autocollect is triggered.

Uploaded a new patch (see changeset 6), which avoids errors if ever PHP failed to determine the dimensions of the PNG, or if the desired data couldn't be read in the JSON retrieved from backend.

I have seen your comment on Gerrit. Indeed, it was a shame to fetch the PNG every time from backend to get its dimensions. As I stated above, I previously made an attempt at implementing a sidecar metadata file, but it got too much complicated, mainly because of the diversity of code flows. Though, I just did another attempt with fresh mind (and meanwhile discovered the "create" backend operation instead of "store", which helped to keep the code simple)…

I suppose you mean conditionally loading the templatestyles from Lua, using frame:extensionTag as described here: How can Lua modules interact with styles?

Similarly, I just noticed these mw-empty-elt elements aren't hidden in the "printable version" too (example).

I understand this code better now (didn't notice there are 2 ways of generating the PNG: default using ploticus only, and "svg2png").

Rather than reading the entire PNG to get its dimensions, maybe we could store them in a sidecar file? (something like {$pathPrefix}.dimensions)

After numerous tries, it was a permission issue indeed.
Uploaded to a separate changeset, so you can at least see my patch: 690771.

Using the Gerrit Patch Uploader, even after proper rebasing of my patch, I'm encountering this error:

Rather than the getimagesize( $url ) in above patch, a better code could be:

• Without anchor, location.hash is an empty string; with "#" anchor, location.hash is still an empty string; then with "#x" anchor, location.hash becomes #x. Therefore, location.hash is never #.
• jQuery constructor can work without argument, or null, undefined, empty string, empty array… all these return an empty collection. (reference)

So, with https://gerrit.wikimedia.org/r/664228 the simple EventSingletonManager utility gets a dependency on the heavy and unrelated OOUI…

Agree with Krinkle.

No problem at all!
And the fix seems to be significantly more complex than I thought, so thank you for your work on it!

Firefox shows this warning:

Thanks, though I think it's still a bit too emphasized. How about the Base50 #a2a9b1, or at very least Base40 #8a9097?

Useful addition, though, may I suggest making these numbers lighter? They add a lot of visual distraction, yet they are needed only in a few situations.

Despite the above patch, the problem is still present on frwiki…

Refs discussion on French Wikipedia

Hi, using the "Download as PDF" feature on French Wikipedia, I noticed that the sidebar is included in the generated PDF, contrarily to a PDF generated on e.g. English Wikipedia.

Following up to my above comment, there is no longer a linebreak between the "From date" and "To date" inputs since the form has been converted to OOUI, refs T117736 :)

Though personally I don't understand the need for this feature, it seems a lot of users requested it and find it useful. So that's fine :)

Could you please provide a user setting for disabling this feature?

For your information, here is a script of mine, that I had developed to give full horizontal space to the content:

I would like to clarify, are you (the devs) going to keep or revert the switch to monospace?

Look just above, the font <del>has been</del> <ins>is going to be</ins> restored to sans-serif.

Just as a reminder, the changeset has been reverted

Personally, after some initial reluctance, I tend to prefer the monospace, but I had to tweak the font in my user CSS.
The font really has to be fine-tuned, and it certainly varies a lot depending on the OS/browser/etc.

Just found T176636 already.

Some "Git blame" led me here ;)

Closing, as it was a mistake on the wiki actually. Refs the discussion, and the fix I have applied (removal of the inappropriately used mw-editsection class).

Could anyone think of any issues, to have categories but without their code in the final wikitext?

I have added a code comment on the Gerrit patch.

T155347 is ready and awaiting for more than two years 😭

Following-up to this commit,

We had a related issue on frwiki (see talk, involving template Liste éléments):