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. >.>

Or... three.

(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.

Okay yeah I'm filing that under user error. >.>

Turns out something changed.

:DDD

Given I was seriously considering removing even the option of using a word in timeless in the name of saving space, I'm just gonna decline this one. >.>

Can someone verify if this is still an issue? I can't reproduce now, but if it's just been fixed locally, it could still perhaps use adjusting skin-side, depending on what it is...

The languages menus are only supposed to be showing up like this when no languages are there to support tools like wikibase adding/editing links via the menu.

So for our explosion of user settings here, we're potentially looking at:

• checkbox: enable fixed-position header (this)
• select: column-layout T131803
• select: theme T131991
• checkbox: disable max-width for text pages T231459

Hmm, we might be able to change the position of the shadows, and do some horrible hacks to the caption to get it to cooperate after all...

In T201734#6674929, @Izno wrote:

See also T257717: Wikidata property value styles are not responsive and have massive excess padding/margin across resolutions.

Good enough probably.

Pictured issue appears to have been resolved at some point.

I was wrong, this turned out to be a lot simpler than I thought. I... think.

Yeah, seems fine now...

Yeeeeah. Maybe.

In T179265#6688944, @1997kB wrote:
Tables like https://en.wikipedia.org/wiki/Wikipedia:Sockpuppet_investigations are no more workable on desktop as one has to go all the way to the bottom for horizontal scroll. Maybe make the table scroll with mouse?

In T179265#6688944, @1997kB wrote:

Tables like https://en.wikipedia.org/wiki/Wikipedia:Sockpuppet_investigations are no more workable on desktop as one has to go all the way to the bottom for horizontal scroll. Maybe make the table scroll with mouse?

I've done this now for Timeless in the TemplateStyles page as a workaround.

Okay maybe 2 is possible but it scares the bejeezers out of me so I'm just gonna pretend it isn't.

Eeeeh technically... ish. >.>

Okay, I have noooo idea if the above will actually fix this or not. Given the stickytableheaders gadget appears totally unaffected (as in, still broken) I'm not hopeful. Then again that might actually be the css not getting along, so maybe cleaned up js will help this?

1. When displaying a standard wiki table with caption, there is a border around the caption that I'm pretty sure was not there before. I don't think the bar should cause that border.
2. I think the "scroll" bar probably should extend to the top of the tbody rather than the top of the table. Or at least the top of the highest headers rather than the caption. The bar causes otherwise good whitespace to be a sad grayspace extending past what looks to be the visible table, until you realize the caption is there.

Well, the tables exclusion should fix this for infoboxes if other sites' infoboxes are like enwp's, whatever it is. Not that enwp's infoboxes seem affected?

I think targeting both mobile and desktop makes sense here

Uuuuugh I wanna decline this as the existing layout doesn't lend itself well to it and I don't want to fix it, and just say Timeless isn't a skin targetted at wikifarms, but it's... actually deployed on a couple of pretty big ones?

I don't care anymore. If anyone has actual problems they can file a new one with the problems. >.>

...okay, because this was nagging at me and weird and I realised what I did wrong the first time, I went and corrently checkout out the deployed core/extensions/whatever pile currently live on wikimedia (rMW340b2be45285), and... nope, still can't replicate locally.

(Don't worry, though, someone with half a brain should look at this at some point and they should be able to figure it out. >.>)

Scratch that I can't get this version of core to work at all because... vendor doesn't appear to be up to date? I dunno, none of this makes any sense to me, I'm at the end of my rope.

Okay, checking out the same commit, I seriously cannot replicate this. The styles are there, locally. They're just plain not there on wikimedia?

Definitely seeing this on enwp and eswp on monobook, but not vector. (And I ain't logged in, this is just with useskin.)

Maybe next time I'll actually bother to tag all the skins affected that all need the same fix... that might be more useful.

Okay fixed here.

Nope, this is just the top: -5px positioning that every skin but vector pretty much has to override back to 0. (Okay, MonoBook did -1px, but it'd be fine at 0.)

Okay, so trying to duplicate this locally, it looks like it's not that images break in tables with timeless' new styles, but rather that these new styles combined with the wikipedia tmbox (etc) styles break. So I'm really hoping that is still just in tables...

Probably.

But seriously, keep the weirdness coming, man. This is really helpful!

The difference with mbox is the text vanishes, not the images.

Specifically can be seen here: https://en.wikipedia.org/wiki/User:Gwenhope?useskin=timeless

This was fixed... at some point.

Okay, older versions work fine pre-1.35, current should still work with 1.35, we'll shortly make it 1.36+, I reaaaaally don't even care anymore.

Okay, I checked. It's not backwards compatible. Good day.

Yeah okay looks fine.

Given there's no top border anymore... this is effectively resolved!

Though now that we have wordmarks maybe this is fine?

When you wait long enough, problems resolve themselves by becoming irrelevant.

Pseudoelements! Nevermind svg capabilities, just pseudoelement everything!

Eeeeh all the skins do this now. Well, all of mine. :P