Page MenuHomePhabricator

Minerva on desktop doesn't show navboxes (does it?)
Closed, DuplicatePublic

Description

I could be really dumb in assuming Minerva is deployed to production as skin-for-use on desktop (even in alpha/beta), but if I go to World of Warcraft on en.WP with useformat=desktop & useskin=minerva, no navbox displays.

I would guess the LESS in hacks.less shouldn't apply to desktop or should be moved to MobileFrontend from the skin repository?

Event Timeline

Jdlrobson subscribed.

Yep this correct as the config variable $wgMinervaApplyKnownTemplateHacks which is set to true.
The skin should probably not be showing up in desktop preferences and is an unplanned side effect of us pulling the skin out of MobileFrontend. The skins got quite a few problems (tracked in #MinervaNeue_(Desktop) mileston , this being one of them.

I'll merge this into the parent task as we want to show this in such a way that it's useful to users regardless of their screen size : T124168

The skin should probably not be showing up in desktop preferences and is an unplanned side effect of us pulling the skin out of MobileFrontend. The skins got quite a few problems (tracked in #MinervaNeue_(Desktop) mileston , this being one of them.

I accessed it using the link at Skin:Minerva Neue at MediaWiki wiki and just swapped the address to one I knew had a navbox at en.WP. If it is showing up in preferences that is indeed a (good) side effect of making it a true skin. :D

I'll merge this into the parent task as we want to show this in such a way that it's useful to users regardless of their screen size : T124168

That seems reasonable, but I'm skeptical there is any solution in the near term to the really small width problem with the current navbox design, which is why I filed the task specifically for desktop. I would guess the desktop-specific task would be a blocker for desktop use given that's a regression from current desktop skins--my expectation was that a task pointed specifically at the desktop would be easier to solve with a short-term fix while the bigger design question is answered.

That's fair. That particular hack could probably be displayed in a media query.
I had a look at doing this but it's non-trivial as we're using !important in our hacks.
https://en.wikipedia.org/w/index.php?title=MediaWiki:Minerva.css&action=history

In navboxes we could probably relax that... hiding it without important and then revealing it under a media query.
Happy to accept a patch to do that if you're interested in submitting one, otherwise I think T124168 is the place to put the effort.

One nice side effect of removing !important is that it would allow users who want to see navboxes, despite the performance hit and glitches, to do so by adding a line to their custom.css.

Change 369453 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/skins/MinervaNeue@master] Relax navbox hack

https://gerrit.wikimedia.org/r/369453

Change 369453 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Relax navbox hack

https://gerrit.wikimedia.org/r/369453

On the French Wikipedia, we also have .navbox elements, however, they are not <div> but <table> elements.

Thus, the display:inherit makes them inherit the display:block of their <div> container, instead of getting back their display:table, and this affects the layout. Also, inheriting the display property is fundamentally wrong (see this article for instance).

The first solution I thought of was using the display:revert rule. But it has its drawbacks too: not supported by IE (nor by Pale Moon, for the record), and if we were to set the display property of these elements elsewhere, that revert would discard it.

But the proper solution is much simpler actually: just move the display:none to the already existing max-width: @width-breakpoint-tablet media query:

@media all and ( max-width: @width-breakpoint-tablet ) {
	.content {
		/* ... */

		.vertical-navbox,
		.navbox {
			display: none;
		}

}

(and of course remove the ruleset that has display:inherit)

Another point, which is of importance: note the code in this file is affected by the "1px overlap across min-width and max-width" issue, see T310536. I had a look at the codebase using the MediaWiki code search tool, and this issue is present a lot… and the Minerva skin, which is the subject of interest here, has it a lot.