Yeah, no, timeless is breaking it, you're spot on.
Ooooooh this is the image overflow stuff crap.
Tue, Apr 13
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?
Mon, Apr 12
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.
Sat, Apr 10
Like why would any project still be using rasters in this day and age?!
Fri, Apr 9
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?
Tue, Mar 30
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...)
Sun, Mar 21
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...
Sat, Mar 20
Duuur I'm an idiot, I just need to copy the 1.35 fix out of timeless, huh.
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.
Thu, Mar 18
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 :).
...I still don't like the colours. HMM.
Wed, Mar 17
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.
Mar 10 2021
Sorry, guys, this was really throwing me off too, but I was just too tired to do anything about it...
Mar 9 2021
Okay, it's official, I should just bloody fix this already.
Mar 2 2021
On closer inspection it looks like this would break the live preview, but... do we *really* need that? >.>
Feb 26 2021
- 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...
Jan 31 2021
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.
Jan 28 2021
Apparently this is mostly a wikipedia problem?
Jan 27 2021
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.
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. >.>
Jan 23 2021
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)
Jan 16 2021
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 the new Vector, img tags are used rather than CSS
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.
Jan 14 2021
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.
I'd be interested in what a 1.35 version of this would look like and the problems it would solve.
Whoo, fixed everywhere.
Jan 13 2021
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.
Jan 10 2021
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?
Jan 9 2021
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...
Jan 8 2021
This... might actually be something else. O_o
Yeah, that was dumb, should have tested better before deployment. Sorry, guys.
Jan 5 2021
Is this using VE/NWE 2017? And with/without codemirror or any particular editarea-affecting gadgets?