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.

For individual cases/articles, navboxes (and other templates that mobile users are normally excluded from) can be forced using https://en.wikipedia.org/wiki/Template:Strip_nomobile.

This template only provides the editorial freedom to override the exclusion of mobile users. Whether the result is actually desirable (or at least preferable over the default) should be judged on a case-by-case basis.

I've noticed that navboxes do display in the Wikipedia: namespace of English Wikipedia when I look at the page in a wide view (phone turned sideways). It's just that they have extra padding on the top and bottom, and don't display the embedded image (image=). This is my experience using Chrome and Firefox on Android.

@Stevietheman are you using Desktop mode or Mobile mode on phone? I confirmed with my iPhone SE and iPhone 13 on Safari and Chrome browsers; that navigation template doesn't render. For example https://en.m.wikipedia.org/wiki/Foxconn_and_unions, on the other hand, if you call desktop url (without "m") like https://en.wikipedia.org/wiki/Foxconn_and_unions that does render on both mobile phones.

In T124168#9470242, @Stevietheman wrote:

I've noticed that navboxes do display in the Wikipedia: namespace of English Wikipedia

Ignoring the padding question, navboxes are available on most pages besides main space pages per T301578 now.

when I look at the page in a wide view (phone turned sideways).

There is CSS to prevent their display below certain resolutions still.

It's just that they have extra padding on the top and bottom,

This is an artifact of base Minerva CSS which isn't going to be overriden in navboxes.

and don't display the embedded image (image=).

This is T282588#7080109.

@Izno so there's progress on this bug? Using Vector 2022 skin, I went to https://en.m.wikipedia.org/wiki/Template:Multinational_unions which is a non-mainspace page and still cannot see it on mobile view. Can you link an example flow that shows what is different? Or am I misunderstanding your response?

In T124168#9470330, @Shushugah wrote:

@Izno so there's progress on this bug? Using Vector 2022 skin, I went to https://en.m.wikipedia.org/wiki/Template:Multinational_unions which is a non-mainspace page and still cannot see it on mobile view. Can you link an example flow that shows what is different? Or am I misunderstanding your response?

No, the concerns related to this task remain the same and are the reason they remain invisible on mainspace pages. The reason you cannot see it in mobile view is because your mobile view resolution is too small, hence my previous "There is CSS to prevent their display below certain resolutions still." It displays as expected on a desktop resolution today:

Vector 2022 is additionally not a supported skin on the mobile domain. Testing anything with that skin and the m. prefix is not going to get you anywhere.

In T124168#9470292, @Shushugah wrote:

@Stevietheman are you using Desktop mode or Mobile mode on phone? I confirmed with my iPhone SE and iPhone 13 on Safari and Chrome browsers; that navigation template doesn't render. For example https://en.m.wikipedia.org/wiki/Foxconn_and_unions, on the other hand, if you call desktop url (without "m") like https://en.wikipedia.org/wiki/Foxconn_and_unions that does render on both mobile phones.

Mobile (en.m.*), and I'm not talking about mainspace pages (articles). I maintain a WikiProject (in Wikipedia: namespace) and its front page contains a few navboxes.

@Izno - thanks for the explanation. One of the navboxes I'm concerned with was created mostly by me, so I suppose I could rewrite it to not rely on navbox underpinnings, but I sure don't like reinventing the wheel if I can avoid it. And it's probably not worth it just to get an image to display and remove useless padding.

Anything that’s hidden using CSS (rather than removing it from the HTML) can be unhidden using CSS. However, it’s your responsibility to make it readable on small screens if you do so.

What/where is the CSS? With this news, I'd love to update my CSS file to override the mobile configuration then. I thought it wasn't being loaded server side, so this is a welcome change

In T124168#9470724, @Tacsipacsi wrote:

Anything that’s hidden using CSS (rather than removing it from the HTML) can be unhidden using CSS. However, it’s your responsibility to make it readable on small screens if you do so.

OK, I can see doing that if I use TemplateStyles. The image-holding cell has a class navbox-image I can refer to. Thanks! As for readability, I can tweak the width set for the image if necessary.

After looking at the option of manipulating CSS to display the image on mobile, and reviewing the source of output on desktop vs. mobile, there's the appearance that the image is asynchronously loaded, thereby making CSS manipulation via TemplateStyles not workable. Or am I missing something? I've fiddled with visibility and display settings, and nothing works.

I don't know how to put the question: would the use of grid or flexbox be enough to lighten these navboxes? Or is it crucial to also consider the size of the palette content (editorially)? Because while dewiki uses responsive navboxes, they still use tables, which are HTML markup heavy.

Both would tend to lighten them slightly or be a wash (see a commentary I've put together). It isn't fundamentally the overhead setting up the boxes that makes these heavy, it's the fact that people will put 100s of links in each navbox that makes them heavy. Or even 20s of links in each navbox and then having 5+ navboxes on a page. (Or worst, 5+ navboxes with 100s of links.)

Thanks for the link. I was asking because some contributors are pushing (again) for them to be re-displayed on small screens (i.e. mobile) on frwiki. I think the only solution I've been able to find is to allow only one pallet per article, which would also have to respect a size limit. A considerable addition of limits that are unlikely to please.

Maybe it's better to try and convince them that the benefit of displaying this information on a small screen is too limited, compared to the gain of removing it for regions with unstable connections and low-end hardware. This doesn't prevent from reworking the responsiveness of these navboxes for the desktop version.

This led us to think of a second, alternative solution: rework the navboxes so that they are responsive, and display only a link to them on mobile devices (<mobileonly>) so that they can be viewed independently of the article. Except that the solution goes against WMF's desire to display the same thing on every screen.

display only a link to them on mobile devices

I suggested something like this in T124168#7493247.

rework the navboxes so that they are responsive

Yes, this should happen regardless.

I just discovered that mobileonly is only using CSS to hide elements on the mobile version, so it still heavies pages down. It is possible to totally remove the elements like the navboxes are removed?