Yeah, no, timeless is breaking it, you're spot on.

Ooooooh this is the image overflow stuff crap.

Timeless assumes topicon sizes are set appropriately. Maybe this is a stupid assumption, but are you sure you can't just... do that? Set a specific default size in the script?

In T279645#6990123, @Legoktm wrote:

I'll defer to Isarra and co. on the correct way to solve this...it's unclear to me why $wgLogos['icon'] is a single png and not an array with 1x/1.5x/2x/svg options like the main logo does.

Like why would any project still be using rasters in this day and age?!

It's because of T273250: $wgLogos['icon'] notext logo set for newvector is too small to use in Timeless, except we went ahead and used it anyway out of pure spite. Or, more likely, laziness/lack of resources?

Technically Timeless has already switched over, just has the old logos as a fallback. Also needs to deprecate its own custom handling, but that's a separate problem entirely...

T273250 is also going to pose a problem here for any sites using png notext icons. (Mostly wikipedia, I think?)

I've held off on a proof of concept patch for MonoBook for the time being since the WMF config was just nowhere near there yet in terms of having the logos/wordmarks consistently available for all the sites, but once that's a little closer, we should absolutely get on migrating this. (WikiVoyage is a great example why we can't just do it now, though, as some may actually want only a notext logo and thus will only set that, and some do want a wordmark but just don't have one, presently...)

This is funny because I don't even know what this means.

Resolved with some bad css at some point...

Sorry about that, it turns out some of us are just drunk and sleep deprived and that doesn't result in the most meaningful testing...

Duuur I'm an idiot, I just need to copy the 1.35 fix out of timeless, huh.

In T269891#6684977, @Jdlrobson wrote:

FYI In Vector and Minerva we use a checkbox hack for the menus. We've been meaning to consolidate the associated CSS code as a core module.

In T274199#6927223, @Legoktm wrote:

Thanks for putting up that patch but am I correct in understanding if there's no default icon set then there just won't be any logo shown? What is the correct procedure for putting back the already existing logos? That's really what I don't get.

It sounds like you're saying the fix is to not use the new $wgLogos system in Timeless because it's not ready yet - is that correct?

No that's not what I'm saying. I'm saying that every logo needs to be manually created, derived from the old logo and certain projects don't have that yet. I'm saying Timeless can workaround this issue by accumulating technical debt if it wishes.

I think @Isarra's take above is right. Let's do this right for every skin rather than applying more duct tape :).

In T274199#6926997, @Jdlrobson wrote:

...I still don't like the colours. HMM.

Not removing this from Anisa yet after all, as the replacement apparently isn't available in 1.35, and Anisa is still targeting 1.35 and not 1.36... is this still only deprecated as of an unreleased version, or something?

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?