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 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 or 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 s, 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 () 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 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?

I feel like navboxes are gonna have to fundamentally change before they're close to usable on mobile. Making the tables responsive by itself isn't enough; we can't expect any UX/UI designer to fit 1000+ links in a phone screen in a pretty way.

Take a success story from WP:LINKCRISIS, for example: Template:Texas once had a wikilink for each and every one of Texas' 254 counties. That has since been replaced with "See: List of counties in Texas". To me, that's the mentality that can get us to usable navboxes on mobile: instead of listing every tangentially related article, just linking to a list/index of them.

Maybe this could be a separate template, like {{Mobile-friendly navbox}} or whatever. Each section label would require a wikilink to a list/index article and, on mobile, section contents wouldn't be visible at all (and preferrably not added to the HTML in the first place). This could then become a slow burn replacing task, considering the amount of navboxes already in use.

Here's what the current Texas navbox looks like on a Pixel 7 screen size:

And here's what I'm proposing it could become:

Now, for some caveats: not all navboxes are going to be translatable to this model. They would require different solutions.
Also, this entire idea is from my experience with en-wiki; I'm not sure how other wikis handle navboxes, so I can't comment on that.
Finally, this feeling has been previously expressed somewhat on T124168#3716544, though without a proposed solution.

Navboxes are viewable just fine outside the mainspace when in mobile mode, like drafts. Why is this still a problem?

In T124168#10146295, @Kailash29792 wrote:

Navboxes are viewable just fine outside the mainspace when in mobile mode, like drafts. Why is this still a problem?

The implementation changed so that it affects only main space. The "problem" is a deliberate decision, not a bug/"problem".

I think the editors of English Wikipedia can solve this problem on our own by migrating to a new set of templates that are mobile-friendly.

Avelludo, I like your idea very much. I found on other templates as well that having one link for each topic in the left column of the current navbox is a natural solution that makes it easier to navigate these huge trees. Did you have any wikitext that implements your proposed solution?

I think I've read that show/hide functionality is disabled on mobile, and this format is short enough we wouldn't need to roll it up by default or on demand. I'm assuming all the links are targeting separate pages? That would solve the criticism of slow page load times. If they are JS buttons that open sublists on the same page, that would not be a terrible user experience depending on how it's implemented, and would enable a very straightforward migration path.

@Beland Thanks!

Did you have any wikitext that implements your proposed solution?

Unfortunately, no; I sketched that with HTML/CSS directly. I'm not too familiar with template-specific wiki syntax, how one would go about detecting mobile, how to leave out HTML for mobile pages, etc.

I'm assuming all the links are targeting separate pages?

That was the idea! In that Texas example, it would follow pretty much what's already in use for that template: Topics wikilinks to "Index of Texas-related articles"; Regions wikilinks to "List of regions of the United States#Texas"; and so on.

In that template (and most navbox templates I've seen in enwiki), the sections are defined with and pairs; my thought was, for mobile, the contents of the s could be removed entirely, keeping just the (wikilinked) s. This would, at least in theory, make the task of migrating simpler. Cheers!

I think the editors of English Wikipedia can solve this problem on our own by migrating to a new set of templates that are mobile-friendly.

Since you've submitted a template at TFD that I've now seen, I think it's prudent to comment on task (I had written this a week ago). I do not think you can convince editors to abandon how much stuff goes into navboxes, but I especially don't think you can do it in one-off TFDs.

I'm assuming all the links are targeting separate pages

This is not a good assumption for the general case.

I think I've read that show/hide functionality is disabled on mobile

This is no longer true. Show/hide is functional on mobile now, so we won't have the issue with scrolling.

If they are JS buttons that open sublists on the same page, that would not be a terrible user experience depending on how it's implemented, and would enable a very straightforward migration path.

"Load on demand" is more or less what I suggested at T124168#7493247. Loading on demand is the only way to fix the "they're big issue" in a way which could convince English Wikipedia to use any other templates.

But that step is a step in a direction opposite to the way MediaWiki has been going of late, which has been to stop modifying the parsed content, so as to avoid varying the cache solely on content (among other reasons). So I actually don't think that will happen now either.

I guess WMF could build a parser function for this? IDK what the shape of that looks like. It probably wouldn't apply solely on mobile, it would also apply on desktop. However, I suspect loading on demand would have negative SEO impacts as the content would not necessarily be visible to spiders, and if employed for every navbox would have some above the fold impacts with the current military navigation template. (See also the note at the top of the task I guess.) But IDK what the web state of the art is here.

how one would go about detecting mobile

This is not possible in wikitext.

I did write a very short essay about the topic of big navboxes that if implemented would be a ton of work on wiki. https://en.wikipedia.org/wiki/User:Izno/Navbox_constellations This one kind of fits into the "make smaller navboxes" ethos here and might be one direction to approach Wikipedians about the problem. But even the examples in this essay are too large for the direction you (plural) want to go, and I don't find the examples particularly unfortunate, so you're going to have to do a lot more work to convince people.

Change #1175217 had a related patch set uploaded (by DLynch; author: DLynch):

[mediawiki/extensions/MobileFrontend@master] API method to obtain content removed by mobileformatter

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

^ for discussion, here's a patch that adds an API method to MobileFrontend that would make it possible to fetch whatever content was removed from a given page by MobileFormatter. It could potentially serve as the basis of a feature that added some sort of "show excluded content" button on mobile that opened an overlay containing whatever had been stripped out. (Or filtered it down to just the excluded content that's a , of course.)

In T124168#11055673, @DLynch wrote:

^ for discussion, here's a patch that adds an API method to MobileFrontend that would make it possible to fetch whatever content was removed from a given page by MobileFormatter. It could potentially serve as the basis of a feature that added some sort of "show excluded content" button on mobile that opened an overlay containing whatever had been stripped out. (Or filtered it down to just the excluded content that's a , of course.)

That sounds great!

Couldn't a relatively low-tech solution solve this, at least on an interim basis while the underlying problem is dealt with? I would propose a change which for mobile only, would transform transclusions of a Navbox template into links to the Navbox template page itself. There would be nothing to expand; just a bar that looks like a Navbox title bar, but in reality is just a link with nothing hiding under it. This seems doable in the {{Navbox}} template itself.

Thus on mobile, they would always see what looked like a collapsed Navbox title bar, as in desktop view, along with whatever was coded into the title bar itself, but show/hide behavior would be altered. Clicking 'show' would navigate away from the article page and to the Navbox template page itself. (Very large templates might still have a page weight problem, but many would not, and we can detect {{PAGESIZE}} of the nav template and maybe do something else.) To get back to the article, just browser back-arrow, or if some referrer info can be passed in, the [hide] link could be usurped and go back to the article.

One way to do this would be a bit of extra code at Template:Infobox, but haven't thought about the details so not sure if that is the best place. But I don't see anything blocking implementation of this. Am I missing something?

Linking from article space to a template is intrinsically evil.

However, the above system could be made to technically work and would allow mobile users to use the standard aids to onward navigation.

Hi, in the last years more people use the mobile for accessing Wikipedia. The luck of Navbox templates hides the data from the users. Is it possible to implement it on 2026??

This will increase the accessibility between many pages and will achieve better flow for the users that "jumps" between pages.

Priority indicates how soon someone will work on a task, not an indication of importance of the task.

How this issue can be resolved?
Is there an effort estimation for it?