[00:09:03] taylan: hm, how so? what version of MW are you using? [00:09:15] p858snake: LiquidVectorV5Improved ;) [00:09:27] I'm on 1.37... actually it might just be related to custom CSS, let me try again. [00:09:50] ashley: LQT4Lyf *runs* [00:11:58] ashley: the link colors are broken: https://bg3.wiki/wiki/Main_Page [00:12:10] and to be honest I don't like the blue ^^ [00:14:14] hum, weird! but thank you for the report, I'll look into it -- I don't recall seeing that locally but Vector sure has changed a bit recently, eh [00:14:56] oh, okay, your wiki is using 1.37...I've only tested theme with 1.35.x (the current LTS version of MW) but let's see if this could be fixed in a forwards-compatible way... [00:17:13] hmm I really wish DarkVector was a Theme and not its own skin, skins pretty complicated [00:18:10] I had hoped I could copy the directory and magically get a copy of the skin but need to change the name in some places in the code I guess. or I just modify the existing DarkVector in-place, that seems easiest. [00:19:02] well we could probably turn it into a theme ;) and IMO a lot of derivatives (esp. of Vector and of MonoBook, current and former default skins of MediaWiki) *should* definitely be themes and not skins because the forked versions of skins will usually end up outdated and unmaintained; in my experience, more people know CSS than PHP :) [00:19:40] anyway re:broken sidebar link color, it seems that in MW 1.37 there's a new ".vector-menu-portal .vector-menu-content li a" CSS rule which overrides the generic "a" selector...so the patch should be a one-liner, hold on [00:26:39] alright, try this: [00:26:40] (PS1) Jack Phoenix: Dark Vector sidebar link color fix for MediaWiki 1.37+ [extensions/Theme] - https://gerrit.wikimedia.org/r/749904 [00:41:46] trying to figure out how to check that out... [00:43:03] ashley: how do I get that change? clone a different repo? [00:43:30] currently using https://gerrit.wikimedia.org/r/mediawiki/extensions/Theme.git [00:45:44] there oughta be a download option on that patch (though luckily enough it's pretty small so easy to manually apply, too ;), at least when you're logged in...but let's just merge it; if need be, it can be reverted but this seems like so simple that I can't imagine any reason why it wouldn't work [00:49:21] (Merged) jenkins-bot: Dark Vector sidebar link color fix for MediaWiki 1.37+ [extensions/Theme] - https://gerrit.wikimedia.org/r/749904 (owner: Jack Phoenix) [00:49:28] alright, now just run "git pull" to pick up that change :) [00:49:53] (do note that you may need to force-refresh the page after git pull'ing to see the change -- CTRL+F5 on most browsers should do the trick if memory serves me correct) [00:50:01] ashley: seems to have only worked partially: https://bg3.wiki/wiki/Main_Page [00:51:05] the sidebar area looks fine to me? (identical to the 1.35 version I have running locally, as it should be) [00:51:30] I think something's cached here... [00:51:45] it's always caching ;-) (except when it's file perms :P) [00:52:34] but even ctrl + f5 doesn't work O_o it looks fine in a private browser window. [00:53:23] when I reload I briefly see the correct color before half of the links turn blue [00:58:21] weirdest browser issue I've ever experienced. even the dev tools indicate that the computed color is yellow not blue, yet the links are blue... [00:59:09] aha, it's related to the "has been visited" state of the link [01:03:07] ashley: the culprit appears to be ".vector-menu-portal .vector-menu-content li a:visited" [01:03:41] hopefully fixed by this patch which I hope gets merged in a few minutes or so: [01:03:43] (CR) Jack Phoenix: [C: +2] Dark Vector: more sidebar link color fixes for MW 1.37+ [extensions/Theme] - https://gerrit.wikimedia.org/r/749908 (owner: Jack Phoenix) [01:03:53] ty for the quick fixes!n [01:04:30] now I just have to tweak the colors to make it look like DarkVector :P [01:05:40] :) [01:05:54] pulled the commit, it's fixed :) [03:09:55] \o/ [20:39:45] oh man, there's such "class bloat" in this "OOUI" framework that MediaWiki uses... what the heck is this: .oo-ui-buttonElement-framed.oo-ui-widget-enabled.oo-ui-flaggedElement-primary.oo-ui-flaggedElement-progressive > .oo-ui-buttonElement-button [20:40:09] (that's a rhetorical question, I understand what it is, but it shouldn't be necessary to use a selector that long to override some styles) [20:41:48] ashley: FYI I'm working on a variant of the dark theme that allows swapping colors by changing a few CSS variable definitions at the top, but dunno where to upload to make the world benefit from it :P [20:43:37] amen re:OOUI; awesome! do you already know how to use gerrit? (if not, I don't blame you the slightest...it's a confusing mess to learn, for sure :P) if you do, you can submit it there; if not, I could submit it on your behalf (just need a new name for it since "dark" is taken ;) [20:44:38] is there more to it than standard git usage? [20:47:11] slightly, yes; whereas in a "regular" git setup you'd use "git push", here you need a commit-msg hook, the "gerrit" remote set up in the repo's .git/config file and then instead of "git push" you'll use "git push gerrit HEAD:refs/for/master"; I once wrote a very quick 'n' dirty gerrit tutorial aimed at Windows users but just ignore the Windows-specific bits and focus on the git/gerrit workflow: https://en.brickimedia.org/wiki/User:Jack_Phoenix/gerrit (and [20:47:11] yes, this is how *I* do it, it's more than likely _not_ ideal :P) [20:47:44] thanks, will look into it :) [20:47:48] (ended up with this workflow because I kept having issues with git-review ages ago and to date I haven't bothered rechecking if said issues still persist because this works well enough for my needs!) [20:47:55] lemme know if you need any help! [20:55:18] there's also https://www.mediawiki.org/wiki/Gerrit/Tutorial/tl;dr [21:49:51] hee, neat! [22:14:57] also git-review in windows is documented here: https://www.mediawiki.org/wiki/Gerrit/git-review#Windows [22:19:13] ashley: how can I deal with cases where inline CSS overrides the style? should I just use "!important"? date input widgets seem to use inline CSS a lot. [22:30:38] yeah, can't really think of a better solution than changing the specificity of the rule if/when needed + slapping !important on 'em as appropriate >.> [22:56:11] changing specificity seems smart, I guess !important should be left as a last resort / left to individual users to use in their custom CSS [23:18:12] taylan: https://www.mediawiki.org/wiki/Manual:Coding_conventions/CSS#!important has tips about avoiding !important [23:19:15] cool, didn't know you could just repeat a selector to increase the priority