MediaWiki talk:Gadget-oreuiTheme.css

I've noticed a couple of issues with how certain elements are displayed when this theme is used in combination with other gadgets, so I added some fixes to my alt account's custom CSS.

html#stickyTop.stick{
background-image:url(/images/OreUI-background.png?c71a0);
background-size:1920px;
background-position-y:52px;
}

@mediascreenand(min-width:720px){
html#stickyTop.stick{
background-position-x:-11em;
}
}

html#stickyTop.stick#stickyTopBack{
width:calc(100%-var(--sticky-header-left-margin)-14px);
left:2px;
height:2px;
background:#1e1e1f;
}

html#stickyTop.stick#stickyTopBack::after{
display:none;
}

@mediascreenand(min-width:1200px){
html#stickyTop.stick.fixedWidth#stickyTopBack{
width:calc(100%-4px);
}
}

htmlbody.wgl-theme-darka{
color:#70dea0;
}

The OreUI + dark mode combination does have some other display issues as well, though anything else I've found so far would either be low-priority to fix or arguably come down to personal preference. To anyone testing out these fixes, let me know if you come across any issues resulting from them; ty – FireX • talk @ 02:37, 10 October 2024 (UTC)

Thank you, I wasn't aware of the sticky header gadget when making this. However, I find it weird to define desertsunset.png as the background for the sticky header element (I don't know what the ?c71a0 query is supposed to mean, either). Couldn't you just remove the default background from it?

As for dark-mode links, I can't seem to reproduce the problem. -- mschae23 (M_S_72 | talk) 12:34, 16 October 2024 (UTC)

The page contents will incorrectly show up behind the sticky header if I remove its background image. I do admit it's probably not the most elegant solution to fix that gadget's rendering, but that was just the first idea that came to mind.

With dark mode enabled, the base link color gets changed from this to this. The new color is significantly darker and does not contrast well with the background, which is something that gets corrected by my fix above

– FireX • talk @ 15:22, 16 October 2024 (UTC)

Oh, you mean the contrast. I personally think it is fine, but of course, it can be changed for accessibility (although I think the color you choose is too bright).

As for the sticky header, I suppose it is a subjective preference. I've tested it without a background and it seems to make sense to me (and doesn't occlude as much of the page), but it looks a lot weirder than keeping the background. For reference, I've used the following change for the backgroundless version:

html#stickyTop.stick{
background-image:none;
}

@mediascreenand(min-width:720px){
html#stickyTop.stick{
background-position-x:-11em;
}
}

html#stickyTop.stick#stickyTopBack,html#stickyTop.stick#stickyTopBack::after{
display:none;
}

@mediascreenand(min-width:1200px){
html#stickyTop.stick.fixedWidth#stickyTopBack{
width:calc(100%-4px);
}
}

You mentioned there being other issues with dark mode, but other than the search bar border, I haven't encountered any. In any case, maybe it would've been a good idea to rewrite the style entirely – as it was originally a userstyle, I wrote it in a bit of a hacky way, and the fix to the precedence issues (the html prefix to all the selectors) also seems very hacky (is this done in any other theme gadget?). Even if we don't end up rewriting it, thank you for improving it! -- mschae23 (M_S_72 | talk) 17:55, 16 October 2024 (UTC)

I do kinda agree with my link color choice being too bright. I changed it to be slightly darker and more closely align with the brightness of the regular dark mode link color, do you think this new one's better? (old vs. new)

One other issue I've noticed with dark mode is this instance of low contrast, which occurs due to the tab colors no longer changing in dark mode. That could just be fixed by having the dark mode redlink color not apply to the header. I, however, think that we should instead give unselected tabs darker colors with dark mode enabled; the same colors that the sidebar menu headings have would probably work. That's of course a case of personal preference and we should get feedback from other users before deciding what to do there.

If we want to get rid of the sticky header's background entirely, then the media query styles don't do anything meaningful and the fix for that gadget can be shortened to just this:

html#stickyTop.stick{
background-image:none;
}

html#stickyTop.stick#stickyTopBack{
display:none;
}

That's way simpler of a fix than trying to retain a background image, imo. A new issue does arise if we were to go down that route, however: any page contents that are in between the two sets of navigation tabs cannot be directly interacted with. In my previously-linked dark mode image, for example, trying to click the "Wikipedia:Bypass your cache" link doesn't do anything. I'm sure that could be fixed as well, though it might require changing the sticky header gadget itself.

Looking at the other theme gadgets, a majority of the selectors in them have html specificity as well, but not every single selector like this one does – FireX • talk @ 21:23, 16 October 2024 (UTC)

I've added your fixes to the gadget! Feel free to add more if you want to. | violine1101 ^(talk) 12:29, 2 December 2024 (UTC)

Should we replace the background image with a vibrant visuals image? Most bedrock players are using vibrant visuals with minecraft, so i think it wuld be better adding a vibrant visuals screenshot. 👁 Image
Dazzle 👁 Image
14:25, 26 October 2025 (UTC)

Most? Do you have official statistics at hand? — BabylonAS 14:41, 26 October 2025 (UTC)

The background image is already a pretty random image, but I kind of like it. The thing is that this theme represents one of the possible new skins the wiki could've had after the fork, so I'm not sure changing much about it (other than minor improvements and fixing issues) is really a good idea. -- mschae23 (M_S_72 | talk) 06:38, 27 October 2025 (UTC)

Bumping this discussion. I propose to make the background File:Clear panorama BE.png, which is always a high-quality VV image that fits the theme. Furthermore, it is always seen as the background in any Ore UI menu in-game. Using this screenshot has the additional benefit that it gets changed with every update, making the wiki feel themed around that update. MinecraftBedrockPlayer7 (talk) (contribs) 👁 Image
19:09, 26 February 2026 (UTC)

I know I already replied here a while ago saying I wasn't sure changing the background image is a good idea, but I think using an image that actually appears as the background for OreUI menus does fit thematically. -- mschae23 (M_S_72 | talk) 19:45, 26 February 2026 (UTC)

Bump. If no one replies, I'll ask in #wiki-requests for this to be implemented. MinecraftBedrockPlayer7 (talk) (contribs) 👁 Image
20:34, 12 March 2026 (UTC)

While I know CC0 does not require attribution, the gadget has proper attribution anyway, which I appreciate :)

I just wanted to note that I have since moved the Git server from https://mschae23.de/git to https://code.mschae23.de. At the same time, since the gadget is pretty much a “hard fork” of this userstyle, I also believe it would be best to use a permalink to the version that was originally imported here. If I'm not wrong, that should be https://code.mschae23.de/mschae23/userstyles/src/commit/dcb78da6568a8d63c1575bd1ef2419535f6ddd87/src/minecraft-wiki-bedrock.user.css.

Finally, it would also be a good idea to clarify the gadget's licensing. My original version was CC0. I'm thinking (and would support) that the changes made to it on the wiki since then are licensed under CC BY-NC-SA 3.0, like all other pages. But it's also possible they're under CC0 too. Not sure.

None of this is in any way urgent, but if someone who can edit the page could make these changes, that'd be great. Thanks! -- mschae23 (M_S_72 | talk) 20:09, 26 February 2026 (UTC)

👁 Image
 Done | violine1101 ^(talk) 17:42, 20 March 2026 (UTC)