Uses MonoBook styles; nothing to do here.

Sorry, guys, this was really throwing me off too, but I was just too tired to do anything about it...

Okay, it's official, I should just bloody fix this already.

On closer inspection it looks like this would break the live preview, but... do we *really* need that? >.>

Further jankiness:

• Already applied theme disappears when going to appearance tab and needs to be hard-refreshed to get back. Possibly this is the real issue here?
• I was wrong about themes not applying to newvector; that also just needed a hard refresh...

In T98640#6789634, @Legoktm wrote:

It mostly was fine except that all of the 1.5x logos currently in git are 204×234, while the script is downloading 202×232 images.

I've updated https://www.mediawiki.org/wiki/Manual:$wgLogos#Supported_variants - this should make more sense and give you a better guideline what to do now.

Apparently this is mostly a wikipedia problem?

Not really. It's very low cost to add something to MediaWiki:Print.css. You might have a user discoverability problem, but eventually someone is going to say "this is useless in print how do I/we remove it", which is the normal wiki lifecycle. Discoverability is still an issue with "noprint" too.

In T117950#6778896, @Izno wrote:

But wouldn't the main way to set hiding when printing via a Print.css be to specify a class, such as .noprint, that can be widely reused to apply the style within content as needed?

Note that this allows users to consistently apply skin-styles to content, and is thus actually somewhat important. In this case, it should be as simple as applying the .box and similar mixins, or adding them to the same list as in content.css.

This probably applies to all of my skins, bar Anisa, which may actually be the only one using regular monobook interface styles. >.>

In T272764#6770834, @Izno wrote:

Minerva munges the two notifications indicators together, an approach I'm not a fan of TBH. It's an annoyance/confusion when I see big red numbers only to see someone was thanking me.

But seriously yeah this needs... sorting out.

Put two of them with the search... wait, that's a different skin. Though really, why can't this do that too?

Why are there even so many icons? We could reduce them to three...

we should really be encouraging actually square logos somehow, maybe just by breaking this up as standard

So I dunno if I was even complaining about the right things here, but there's basically two issues with the sizing/scaling for hidpi/svgs, mostly boiling down to them not being square:

• Nominal widths of logos fitting in a 130-160px square logo area can vary wildly; assuming 135px wide can mess up both larger width ones (making them just too small) and especially smaller, taller ones (making them too large and then get cut off at top and bottom), so really we should just be telling mw the logo size/width like we do with wordmark images unless they're just squares and it doesn't really matter (skin can set whatever is appropriate instead)
• Logos are generally non-square due to combining wordmark and image logo into a single image; we should really be encouraging actually square logos somehow, maybe just by breaking this up as standard. (Skins like old vector, monobook, etc would then be able to just stack the logo and wordmark on top of each other, and skins like new vector, timeless, etc can do other things with them consistently with the same files)

Although I'm not really sure why the svgs need a size specification to begin with? The svgs should just be the correct nominal size themselves...

In T232012#6752748, @Jdlrobson wrote:

In the new Vector, img tags are used rather than CSS
en.wikipedia.org?useskinversion=2

You appear to be overlooking that this affects svg logos too, and is actually worse there because the 135px assumption hits all resolutions, instead of just >1ppp, when using those.

The purpose of differentiated redlinks is to highlight missing pages and invite (other) users to create them and fill them in with information. A missing userpage is up to the user to fill in or not, and whether or not it exists with custom content doesn't affect that any page with content may still be worth visiting for viewing purposes.

In T62656#6746081, @Jdlrobson wrote:

I'd be interested in what a 1.35 version of this would look like and the problems it would solve.

Whoo, fixed everywhere.

Same as T271473 - fix is merged, should be deployed soon, but you know what, I'm not gonna merge in/close this until then so we actually have something to uuuuh point to?

What about Libertinus?

Specifically affects the 'old look'; the new one uses the correct link.

Anyway yeah this presents as a random inexplicable inconsistency and is an issue regardless.

So, to document somewhere that isn't a random ephemeral chat client, removing the history link text was intentional, but perhaps does bear... revisiting.

Sorry, that probably came out harsher than I wanted. Just... something simpler I could use to replicate similar output to debug with elsewhere...?

Do you have any other, simpler, examples I can look at to try to get to the bottom of this with?

Alright, confirmed this is still happening, also I have noooo idea how the collapsible is supposed to work to begin with or how the... DOM relates to it. Like... is the collapsing stuff even in a separate distinct element?

So part of the issue here seems to be that the alignment is quite off in general - could you clarify what OS and browser you're using? I'm not seeing any clipping, and on mine, this just makes the alignment issues worse. Which likely means there's a font issue or something?

I love you guys.

Okay, confirmed, different presentation of same bug (or cause of bug), but that this was reported too actually ensured we get the right fix, maybe...

I'm... confused. As far as I can tell, the main skin-agnostic interface css appears to have been in 'legacy', whereas for whatever reason, 'interface' has historically and apparently still includes a lot of visual styles specific to monobook-like skins (header borders, colours and padding for things like thumbs, tocstyles, catlinks, etc), and thus cannot really be used outside of these. (But it also has stuff like the thumb icon links that every skin actually does need... and then has to reimplement, so that's annoying.)

Well, I'm not sure yet...

This... might actually be something else. O_o

Yeah, that was dumb, should have tested better before deployment. Sorry, guys.

OOPS.

Is this using VE/NWE 2017? And with/without codemirror or any particular editarea-affecting gadgets?

Okay, this should actually be fixed, for real, for sure, now. Apparently I forgot to define one of the message strings and that was the actual problem. Or another problem. It looks like there may have been several things going on here...

Given most form pages don't have all that many buttons, just defaulting all submits to be progressive may still be fine as long as they behave consistently; action=history with everything and the dog enabled looks pretty weird regardless.

Okay, looks like hassomecolours has at least some of the right idea for applying the overrides consistently even to mw-ui-buttons, we just need... a more neutral version too and to only apply the progressive styles to submits, I guess...

Thanks for the clear report! Very helpful, that.

Linked patch does arrow and search. Rest to come.

...oops.

Confirmed fixed.

Okay, this should now be fixed, but the linked change requires mw 1.36 because I'm a dumbarse and forgot to separate the changes. That being said, if you're willing to hack the skin, you should be able to use just the updated includes/HasSomeColoursTemplate.php file with 1.35 and it'll work properly there, too.

Fixed by Pastakhov in https://gerrit.wikimedia.org/r/c/mediawiki/skins/HasSomeColours/+/622403

Confirmed; this was fixed the other day in https://gerrit.wikimedia.org/r/c/mediawiki/skins/Timeless/+/649110 which should actually be deployed in, uh... next year?

Okay done all the things, or similar, or something, thanks! Very helpful!