Since it's not something that is easy to experience for most people, I made a video of what navboxes + minerva + mobile device currently look like.
https://www.youtube.com/watch?v=eaos1s3UfLs

Even if navboxes looked beautiful on mobile, I'm still not sure I would support including them. Over the years, navboxes have grown larger and larger until now they are often absurdly large directories of articles that may only be tangentially related to the article at hand:

https://en.wikipedia.org/wiki/Template:Technology
https://en.wikipedia.org/wiki/Template:Protected_areas_of_Florida
https://en.wikipedia.org/wiki/Template:Animal_rights
https://en.wikipedia.org/wiki/Template:Global_warming

Scrolling through huge templates like that on mobile is usually just a waste of time (and bandwidth).

In T124168#1948387, @Jdlrobson wrote:

to better suit our users on 2g connections who we believe cannot even access our site without the use of an external proxy - a more pressing issue

I will repeat here from Wikipedia:Village_pump_(technical).

2G is not completely gone, but it will decay over time

https://www.akamai.com/us/en/about/news/press/2017-press/akamai-releases-first-quarter-2017-state-of-the-internet-connectivity-report.jsp: average 2.8 Mbps in Venezuela

We cannot give Internet if they cannot have one. Better to support blind and deaf people than minorities with slow net.

In T124168#3716544, @kaldari wrote:

Scrolling through huge templates

It is a problem with CSS. It should be 1D scrolling and not 2D scrolling

Some progress can be done with current flexboxes:

• http://jsfiddle.net/mh7vqt23/3/
• http://jsfiddle.net/ozx7tc6o/

Possible version without nested navboxes: http://jsfiddle.net/mh7vqt23/11/

I'm skeptical to make it without JS at this moment.

<s>I'm stuck with "alignAsides" http://jsfiddle.net/mh7vqt23/8/ when iframe is 1280px wide: it should update asides but also to ignore asides from .flexnav-forced-column (first aside should get width of second, but not third)</s>

In T124168#3716544, @kaldari wrote:

Even if navboxes looked beautiful on mobile, I'm still not sure I would support including them. Over the years, navboxes have grown larger and larger until now they are often absurdly large directories of articles that may only be tangentially related to the article at hand.

I would respectfully argue that this is not the issue at hand. I agree with you that there are many examples of hugely cumbersome navboxes. However, it should not be the decision of the the software developers which parts of a Wikipedia article are or are not displayed for aesthetic reasons. Working out HOW to better display thigs such as infoboxes (let alone how to edit them) is a topic of much interest and debate - but it would be 'overreach' for the developers of the mobile interface to decide that because they think infoboxes are sometimes/often cumbersome to read, that they should not be displayed to anyone.

We *should* have a discussion on-wiki for how to better utilise the value/power of navboxes. And, removing them from the mobile version for serious technical reasons is a valid argument. But, IMHO, developers should *not* be refusing to display them because of *content reasons*.

In T124168#3732780, @Wittylama wrote:

they should not be displayed to anyone

It should be a configuration option, similar to other question(s).

Like nobody knowns what to do with TOC, but we have have several setting options.

Please note that some Wikipedias have very restrictive policies about navboxes (eswiki doesn't allow more than three lines and those which don't offer more than categories), so the consumption argument wouldn't apply. For current mobile and app users this lack of information is not a minor bug.

The latest Iphone Wikipedia version 5.7.3 use the concept of 3D Touch and Peek quick actions that feels to be a perfect match for implementing navigation boxes and Authorization data..., were you have one start point and many destinations.....

For the user

1. In the app Press hard --> a preview is shown
2. When the preview is shown swipe the peek upward, the system shows the peek quick actions you’ve associated.... ==> could be the different alternatives for navigation ....

See developer.apple.com "Getting Started with 3D Touch"

I'm going to float an idea here to see about technical feasibility of a sketched idea (or maybe to spark a similar idea--maybe with Lua tables instead). (TheDJ's comments above are pretty cool idea too I think.)

Since we have available to us json pages on-wiki, would it be reasonable/possible to rework the template such that each page which is currently a navbox becomes a wrapper of a navbox and a separate json page, e.g.

{{navbox|Links-for-X-topic.json}}

Where template turns the json file into wikitext/HTML?.

Then, where mobileFrontend sees navbox, it goes looking for the json page and can do whatever it wants with them (could be something like DJ's comments above, could render/load a few in the same way as Related Articles... other ideas ~).

Hiding navboxes indeed brings inconvenience. For example, https://www.mediawiki.org/wiki/Extension:Cargo . Maybe we can use loadboxes, see https://minecraft.gamepedia.com/Template:LoadBox .

In T124168#1948388, @Jdlrobson wrote:

I can add some background on why they are hidden (tldr is that this is a trade off to better suit our users on 2g connections who we believe cannot even access our site without the use of an external proxy - a more pressing issue ):

• navboxes table based layout are the least mobile friendly of all editor based content and would need a complete rewrite by editors to be mobile friendly (it does not lend itself nicely to responsive design). There is also currently no way to style content differently on mobile to desktop (a rfc has been open for 4 years now to drive that [1])

Well, at least this part is no longer relevant thanks to TemplateStyles.

• they are html heavy (up to 10% on most of our larger articles) which adds to the bloat to our HTML which renders our site unusable to users on a 2g connection (reference list being the other contributor which is luckily in our control to fix). we need to make it possible for readers to load this separately.

Does anyone imagine a way to rewrite them to be OK in this regard?

Various people from all kinds of wikis keep asking me why aren't they shown on mobile :)

Just wanted to add: for dewiki (where navboxes have always been visible on mobile, but we certainly use them less frequently than enwiki does) I have created a responsive mobile version: examples. Should be live soon. Obviously this is just about the design, the problem of the heavy HTML remains.

Please also note that .navbox doesn’t necessarily mean a such complex and non-mobile-friendly table-based thing. For example, the authority control box at the bottom of https://hu.wikipedia.org/wiki/Barack_Obama is responsive and looks good on mobile as well (the boxes above it don’t, I know), but not even an !important rule can display it as long as it’s not present in MobileFrontend’s HTML output.

Well, but why does it use this class then in the first place? Navboxes on dewiki are visible because we never used the class, there is absolutely no need for it.

Because it builds on the same basic visual styles (colors, spacing etc., even the rule that collapses horizontal borders applies to table.navbox + table.navbox, not table.navbox + .whatever). If we used another class, we would need to duplicate all rules (quadruplicate in case of the border collapse rule: .navbox+.navbox, .navbox+.whatever, .whatever+.navbox, .whatever+.whatever). Actually last time I tried it with another template, not even navboxlike would work as all elements were deleted from the HTML source whose class attribute matched the .*navbox.* rule, even if it was not matched by the .navbox CSS selector…

Lovely. That’s the issue with mixing structural global semantics and local decoration (as already criticised in T262093) …

I don't mind if the css is slightly different in mobile...but it's getting a bit ridiculous that a foundation with $100,000,000+ is unable to figure out a solution for English Wikipedia at this point or hire someone who can for a nearly 5 year old exclusionary bug.

Do these limitations to mobile telephones from 2016 STILL apply to Mobile telephones in 2021? Half a decade has passed and technology marches on. I don't get why Wikipedia has to stay behind.

In 2021, the visitors of the site still cannot see the Navigational boxes. We have to fix it.

In T124168#7369353, @DonTrung wrote:

Do these limitations to mobile telephones from 2016 STILL apply to Mobile telephones in 2021? Half a decade has passed and technology marches on. I don't get why Wikipedia has to stay behind.

Yes, the concern is parts of the world where they do not have access to 3G or later mobile networks and where the raw size of the navboxes is non-negligible; i.e. this task needs fast/cheap networks everywhere to be resolved, or some other alternative devised to that problem.

That said, we have the technology to lazy-load references these days (c.f. T123328: [GOAL] Lazy load references in mobile skin, later removed in T222373); maybe that can be resurrected for the navbox and vertical-navbox classes (and maybe nomobile too, haven't decided on that one). T258424: A way to have sections only load their data once a button has been clicked or when the section is scrolled into view seems to have been filed in the meantime since as well. Which I guess was mentioned above in the first response:

At the dev summit we talked about how mediwiki ideally would allow template fragments such as navbox to be lazy loaded but that's not happening any time soon.

That's besides my idea in T124168#3997564.

I feel that we absolutely need navboxes to be made fully visible for anyone and everyone who is using a mobile device. i feel that this needs to be made a top priority forthwith. i would appreciate any input or ideas on this. thanks.