Change #1066438 had a related patch set uploaded (by Ebrahim; author: Ebrahim):

[mediawiki/core@master] Fix collapsibleFooter regression

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

Test wiki created on Patch demo by Ebrahim using patch(es) linked to this task:
http://patchdemo.wmcloud.org/wikis/eb49b041ed/w/

Change #1066438 merged by jenkins-bot:

[mediawiki/core@master] Fix collapsibleFooter regressions

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

On the "Wikidata entities used in this page" section, the toggle is shifted down. It is because there is a background-position: left bottom CSS somewhere.

It is the only section that is affected, as it seems to provide the toggle in a different way than the other sections (which by the way complicates things further).

@Od1n Can you provide a screenshot and where you are seeing it? Thanks

I can reproduce it:

• on all browsers: Chrome, Firefox, Pale Moon…
• on all wikis: enwiki, frwiki…
• on all skins: Vector, Vector 2022, Monobook, Timeless, Modern… and even Minerva.
• whether logged in or not.

For example on good Vector:

And on Monobook:

It is also visible in your screenshots on T373315.

FWIW, if I recall correctly, at some point the text was not fully to the left, but it had some indentation, so that it wasn't overlapping the icon (which was already misplaced, as currently).

Oh the Wikidata one, It will be fixed the next week, hopefully, if we won't see any other surprise.

Actually it should be seen now,

So maybe something else also went wrong?

I have just tried again, and it looks fine now. Probably just some deployment delay.

Though, there is still the margin issue on Monobook.

Change #1069107 had a related patch set uploaded (by Ebrahim; author: Ebrahim):

[mediawiki/skins/MonoBook@master] Remove spacing above used template

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

Though, there is still the margin issue on Monobook.

That's doesn't seem like a recent regression but the above patch addresses it,

I think you were referring to some issue with arrows placement also, I filed a related regression here T373658 also

Change #1069107 merged by jenkins-bot:

[mediawiki/skins/MonoBook@master] Remove spacing above used template

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

If we want to keep this spacing, we could do:

.mw-editTools + .templatesUsed {
    margin-top: 1.5em;
}

And in Wikibase extension:

.mw-editTools + .wikibase-entity-usage {
    margin-top: 1.5em;
}

• The first code snippet relies on the fact that .templatesUsed is always outputted, even when there are no templates used. But that's how it always has been. If ever that changes, the CSS in MediaWiki core would neverthess have to be adjusted accordingly.
• This code is future-proof, in the case that another extension would add another collapsible section.

I would lean towards restoring that spacing, because having space around the above box .mw-editTools makes things look less cluttered.

If we want to keep this spacing, we could do:

Tbh I didn't think about this solution but that needs Wikibase to have a MonoBook specific style also I think? I just went for fixing what you were reporting as an issue, if you want to restore it it's fine to me though I like some approach that wouldn't need such selectors and reorganization of the whole part with some structured API.

but that needs Wikibase to have a MonoBook specific style also I think?

I hadn't thought about that…

Fortuitously, because the .templatesUsed collapsible section is always outputted, we could more simply do:

.mw-editTools {
    margin-bottom: 1.5em;
}

This would also be structurally consistent with the .editOptions area above, which has a margin-bottom: 2em; rule.

I have looked on other skins (Vector, Vector 2022, Timeless, Minerva…), and it would be better too to add some spacing below .mw-editTools.

In particular since the latest changes, because the collapsible sections now have larger line heights, thus appear more spaced apart from each other.

Something like .mw-editTools { margin-bottom: 1em; } would fit great on all skins.

Stricter variants, to add the margin iif there is at least one collapsible section below (i.e. avoid adding the margin when there is no collapsible section):

.mw-editTools:has( + .wikibase-entity-usage, + .templatesUsed, + .hiddencats )

.mw-editTools:has( + :is( .wikibase-entity-usage, .templatesUsed, .hiddencats ) )

(I prefer the latter)

Note that on enwiki, that .mw-editTools element (see MediaWiki:Edittools) is fully emptied (thus, it no longer displays anything) using JavaScript:

The MediaWiki:Gadget-charinsert-core.js script (which is enabled for everyone) moves the content of that element between #wpTextbox1 and .editOptions. Unless user has set window.charinsertDontMove in his common.js.

As a result, in this case the "margin-bottom:2em" of .editOptions becomes extraneous, and ideally should be removed.

Added on frwiki: 217952935/218783812.

Edit: then completed in 218797570, then corrected in 218797570/218816367 because these elements are outputted even when they have no content.

In T373286#10164114, @Od1n wrote:

As a result, in this case the "margin-bottom:2em" of .editOptions becomes extraneous, and ideally should be removed.

But in turn, if the .mw-editTools is emptied, then the "margin-bottom" of the above .editOptions remains useful actually, but unexpectedly for another purpose: for spacing with the collapsible sections… (and that 2em margin is too large)

If the JavaScript code were to remove the "margin-bottom:2em" of .editOptions, it should also add a new margin, but for spacing with collapsible sections *only*…

To summarize, for real clean margins, the JavaScript code should do something like:

if ( !window.charinsertDontMove ) {
    mw.loader.addScriptTag( `
        .editOptions:has( ~ .mw-editTools:empty ) {
            margin-bottom: 0; /* undo the default "margin-bottom: 2em;" */
        }
        .editOptions:has( ~ .mw-editTools:empty ~ :where( .wikibase-entity-usage, .templatesUsed, .hiddencats, .limitreport ):not( :empty ) ) {
            margin-bottom: 1em;
        }
    ` );
    $( '.editOptions' ).before( placeholder );
}

Of course, that CSS would better fit in the associated MediaWiki:Gadget-charinsert-styles.css. And for targetting only in mode "not charinsertDontMove", adding a class for matching, instead of :empty which doesn't seem very robust (a single whitespace would defeat it).

Test wiki on Patch demo by Ebrahim using patch(es) linked to this task was deleted:

http://patchdemo.wmcloud.org/wikis/eb49b041ed/w/