Tue, Mar 2
On closer inspection it looks like this would break the live preview, but... do we *really* need that? >.>
Fri, Feb 26
- 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
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
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...
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.
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?
Dec 22 2020
Dec 20 2020
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.
Dec 19 2020
Dec 18 2020
Dec 17 2020
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?
Dec 16 2020
Okay done all the things, or similar, or something, thanks! Very helpful!
Skins don't need to concern themselves with hooks, they just need to use the methods in core.
(And to check the menu... type, you still need to check for multiple possibilities. The block containing the trigger may be display-noned most of the time. It may just be off the page in some crazy -9999px left or something. Some skins, like timeless, may do both at different resolutions.)
So the problem is, this part of ULS isn't going to behave correctly in terms of positioning in any skin that uses a dropdown for the personal menu. This'll happen in any of them. Never even mind the fixed header winding up over it on timeless, the thing showing up behind the menu on hover is actually a bit of a mercy compared to how it always appears, covering up the rest of the menu, when trying to get to the rest of the menu, if the layering is fixed...
Is this the deprecatedHookHack stuff in getPortlet?
Gonna be honest, I don't even remotely understand the skin stuff that supports this. So I dunno how to remove it. >.>
Dec 15 2020
(Reopen if it still seems off in a week or two when deployed, I suppose.)
This doesn't solve the weird ptag template on mw.org, but I gave up on that ever making sense years ago.... should be more accurate for most normal use, though.