This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 20 | Archive 21 | Archive 22 | Archive 23 | Archive 24 |
Hi there! I come here from Template_talk:Taxonbar#Making_Taxonbar_mobile-friendly_and_serve_half_of_all_Wikipedia_readers. As you may be aware, many navboxes are unusable on mobile and break the reading experience and as a result are removed by brute force from the mobile site.
This was meant to be a short term solution, but as with most short term solutions has become long term (see phab:T124168. I'm keen to make steps to rectify this beginning with the Template:Taxonbar, however I need a slight adjustment here to allow me to do this.
My hope here is to provide a general solution that can be applied to other templates.
Any element with the `navbox` class will be removed from the HTML on mobile, so to workaround this issue and allow experimentation in the area, a temporary parameter is needed that will allow us to use a different class to e.g. `navbox-experimental`. Feel free to name this parameter/class anything that makes sense. It could also be mobile=1 and `navbox-mobile-friendly` for example. The important thing is the `navbox` class should not be added.
e.g. proposed change:
local nav = res:tag('div') :attr('role', 'navigation') :addClass('navbox') :addClass(args.navboxclass)
to
local nav = res:tag('div') :attr('role', 'navigation') :addClass(args.experimental ? 'navbox-experimental': 'navbox') # not sure if this is valid Lua code but hopefully it's clear what I'm trying to do here. The class should be navbox-experimental when the flag is set. :addClass(args.navboxclass)
Is this possible? If so I promise to report back when I have something cool to show. Jdlrobson ( talk) 23:24, 24 November 2020 (UTC)
I noticed that this template uses the title of the navbox as an ID (:attr('id', mw.uri.anchorEncode(args.title))
). However, it cannot be assumed that these IDs will always be unique, which creates invalid HTML. For an example of this, see the article
Madame Nhu, which has a section titled
Buddhist crisis, as well as a navbox
Buddhist crisis. The fact that navboxes are usually present on related subjects makes such occurrences likely. I propose that when the ID is created, that it be prefixed with "navbox_" so it doesn't clash with any section headers or user-added anchors.
Opencooper (
talk) 17:01, 17 December 2020 (UTC)
document.getElementById("Buddhist_crisis")
on the Nhu page and you'll only get the header). Currently I see the following inline style being applied: font-size:114%; margin:0 4em
. Given that eventually the goal is to move inline styles to
TemplateStyles, this might end up happening inadvertently.When specified on HTML elements, the id attribute value must be unique amongst all the IDs in the element's tree(note, "must"). Given that we could make our HTML valid just by prefixing the ID, I think this should be addressed. Opencooper ( talk) 17:39, 17 December 2020 (UTC)
Using the "|groupwidth = #em " parameter appears to force extra whitespace and widen the group column of a subgroup, but is there a way to force the column to be narrower? I am asking because a long group name can force extra whitespace into all of the other group names. I can insert <br /> line breaks manually to adjust this, but I was wondering if there is a way to let auto-formatting take care of that via a fixed groupwidth. - 2pou ( talk) 19:54, 17 December 2020 (UTC)
|groupstyle=width:8em;white-space:normal;
should do it, or whatever width is appropriate. Thanks!
Plastikspork
―Œ(talk) 14:57, 18 December 2020 (UTC)
Inside the template Template:Trade unions in Myanmar navbox for list2= item, I am forced to put something there, otherwise even the group2 won't show. Does anyone have a work around, besides for empty/invisible string? Shushugah ( talk) 21:40, 25 February 2021 (UTC)
|list1=
, having what are currently your "groups" under * and all of the values in "list1" having ** indentation. That will still give you the necessary splits without having to bodge things up.
Primefac (
talk) 15:28, 26 February 2021 (UTC)This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
I think that |status=
would be a decent alias for the existing parameter |state=
. Or at least, this seemed like an intuitive option
to me, here; and templates should be more user friendly if possible. Now I don't know enough about template syntax to know what needs to be done, so asking nicely here in case somebody with more of a clue can help.
RandomCanadian (
talk /
contribs) 14:18, 26 March 2021 (UTC)
Would it be possible to set a preference or some CSS so that navboxes and their collapsed sections are all visible to me by default? NemesisAT ( talk) 12:01, 9 May 2021 (UTC)
style=""
attribute of table rows to add or remove the declaration display: none;
. --
Redrose64 🌹 (
talk) 19:51, 9 May 2021 (UTC)
The template documentation says of its image field that "Typically it is purely decorative"... yet MOS:DECOR says "Icons should serve an encyclopedic purpose and not merely be decorative." Should the documentation reflect that, and discourage images that only add decoration? If so, where's the line drawn for what's "decorative"?
I had the policy pointed out to me by someone removing a picture of a potato from Template:Potato dishes, which is maybe fair enough, but that kind of usage seems fairly common across navbox templates. -- Lord Belbury ( talk) 17:59, 12 January 2021 (UTC)
They should provide additional useful information on the ... subject, serve as visual cues that aid the reader's comprehension, or improve navigation.is good advice. -- Michael Bednarek ( talk) 12:10, 22 January 2021 (UTC)
Would it be possible to make this module more localization friendly? Given that other wikis use it, it would be great if you could specify localized parameter names (and values like "autocollapse", "collapsed", "expanded", "plain", "off" etc.) so that they could be used alongside the original, English ones. – Srđan ( talk) 09:56, 5 April 2021 (UTC)
changer
is a function and code
is set as its parameter when changer
is called. That occurs in the final gsub
which calls the function for each match of REGEX_MARKER
. That part of the module is extremely tricky, good luck!Re needsHorizontalLists
and your FIXME: I don't follow. The original code adds the tracking category
Category:Navigational boxes without horizontal lists if parameter listclass is not one of the named classes (plainlist, hlist, etc.); same with parameter bodyclass. I guess you know the module wouldn't work at the moment because it would try to index a nonexistent variable (list_classes
).
Johnuniq (
talk) 07:11, 17 May 2021 (UTC)
{{
•}}
template, which was very bad for accessibility. Back in November/December 2011 we decided to sort this out, with edits
like this. The category was used to find out what still needed fixing. WOSlinker was heavily involved. --
Redrose64 🌹 (
talk) 20:08, 17 May 2021 (UTC)You are invited to join the discussion at Wikipedia:Village pump (proposals) § WikiProject links in navigational templates. -- Trialpears ( talk) 16:02, 8 July 2021 (UTC)
Hello. I added a navbox to Web testing, with no state, so I assume it is defaulting to autocollapse. Interestingly, it is choosing to fully collapse, despite there being no other navboxes on the page. Any idea why? Is this expected behavior? Thanks. – Novem Linguae ( talk) 06:49, 14 May 2021 (UTC)
{{
multiple issues}}
; the two templates that it encloses have no bearing on the matter. --
Redrose64 🌹 (
talk) 17:40, 14 May 2021 (UTC)
{{
Ambox}}
which does the work, so this doesn't happen? --
Michael Bednarek (
talk) 00:38, 15 May 2021 (UTC)
Hi! I am using this template on my MediaWiki site and it's in the default Template namespace (10), however, I also have an additional namespace for templates (4010), the site is configured to allow everyone to edit 4010, but not 10 (which is reserved for synchronized from latest versions of widely used templates). I noticed the V T E links at top-left corner of the navbox links to Template (10) namespace, but I want to configure it to use the custom site 4010 namespace. Is there a way to do this in the {{Navbox...}} wikitext markup? I see the Navbar module appears to have a configuration for the template namespace to use Module:Navbar/configuration#L-4 but I don't think the Navbox template passes this to also be configurable. Jasonkhanlar ( talk) 04:26, 3 May 2022 (UTC)
Thanks to Frietjes and Plastikspork's recent work, the navbox class is no longer used in the wild unless through a template driven by Module:Navbox. As such, I've sandboxed changes (see also Module:Navbox/configuration and Module:Navbox/styles.css) to the module which enable TemplateStyles in the template in preparation for removal from Common.css.
I've also finalized the improvements listed in the localization discussion earlier this year.
The sandboxes are currently 'passing' (behavior is replicated between old and new), so please take a look at those and any favorite navboxes you might have to see if behavior has changed in those as well.
Some potential improvements for this release besides the TODOs in the sandboxes would be:
Other major improvements that could be done but I'm not doing now:
Questions/concerns welcome. Izno ( talk) 01:29, 16 November 2021 (UTC)
pairs
would normally be used but that could read arguments in a strange order conflicting with the comment that the intention is to make reference numbers appear in the right order.
Johnuniq (
talk) 03:37, 16 November 2021 (UTC)
fontstyle = (args.basestyle or '') .. ';' .. (args.titlestyle or '') .. ';background:none transparent;border:none;box-shadow:none;padding:0;'
with something that just extracted the last "color:" parameter. the reason for the background:none transparent;border:none;box-shadow:none;
is to override prior values potentially set in basestyle and/or titlestyle, so we end up sending a bunch of extraneous styles to navbar. but, what we have works, so maybe it's not worth the extra processing.
Frietjes (
talk) 15:10, 16 November 2021 (UTC)
style=";"
which it would be nice not to send if we can avoid it.
Izno (
talk) 02:06, 18 May 2022 (UTC)
sanitizeCSS
with something that extracts the last color from the css
like this. I don't think there is any other css that we should allow for styling the navbar.
Frietjes (
talk) 14:43, 18 May 2022 (UTC)
Some followup!
I have removed the Lua that deals with titlegroup out of the sandbox. The category dragged up nothing in the past month. I'll remove this when I sync the module later.
Separately,
I have adjusted the CSS in the TemplateStyles page due to
this series of edits.
Neveselbert identified that the .navbox th
style, when appended with the .mw-parser-output
and subsequently embedded into a page by TemplateStyles, would override the table header styles of wikitable
tables, which apparently impacted succession boxes in particular.
What this second change means is that handcrafted tables in navboxes will no longer be styled after removal from Common.css some time from now while the TemplateStyles styles are updated by the job queue again. ( Neveselbert, please leave a talk page note in the future with an appropriate ping so that we can get this sorted quicker rather than a month down the road.) I see in the history of MediaWiki:Common.css that this has caused some consternation in the past, but with so few templates, the majority now using at least the same 'external' appearance via the module (i.e., the table header/title), and the fallback being fairly graceful to uncolored embedded tables, I feel comfortable fixing the CSS this way.
There are approximately 900 affected templates, which are now probably mostly using Module:Navbox top and bottom in case anyone should care to fix those in the future. Fixing the 900 templates involves probably 1 or 2 possible paths:
Please let me know if you have significant heartburn. I will leave a pointer about this change at VPT and at Common.css. Izno ( talk) 22:23, 21 December 2021 (UTC)
|titlegroup=
and related parameters have also been removed. :D :D :D
Izno (
talk) 04:42, 10 January 2022 (UTC)
hi everyone. I have a simple formatting question, about our template:navbox. how would I put a simple horizontal bar across the navbox, with some text inside it, to delineate a separate section?
please note, this bar does not need to be the top of a collapsible section; it is simply for visual purposes only, in separating one part of the navbox from the other parts.
appreciate any help. if you want, you can simply link me to an existing navbox which would have this feature. thanks! -- Sm8900 ( talk) 13:47, 16 June 2022 (UTC)
<hr />
tag before the |groupn=
parameter. --
Redrose64 🌹 (
talk) 14:41, 16 June 2022 (UTC)I have learnt in another discussion that there was a deliberate decision by the developers that Navbox is not supposed to be displayed on mobile devices, because they don't work properly. But the problem slowly increases as the percentage of mobile users has reached 65% of pageviews and even more critical as the Premier League is affected. Imagine a premier league match is streamed on mobile devices with only one team visible because the other team doesn't work properly. {{ Tottenham Hotspur F.C.}}, {{ West Ham United F.C.}}, {{ Manchester United F.C.}}, {{ Chelsea F.C.}}, {{ Liverpool F.C.}} and all the others are beautiful creations based on hard work using Navbox but they are invisible on mobile devices. No substitute is available on the template bench of Wiki for the incomplete {{ navbox}}. How can we kick off a new discussion to vote for the development of a technical solution of this problem? Ruedi33a ( talk) 16:38, 30 August 2021 (UTC)
Should we depreciate the use of |image =
parameter from the navbox, as a result for
Wikipedia:Navigation_template#Navigation_templates_are_not_arbitrarily_decorative.
112.204.221.155 (
talk) 16:43, 11 September 2022 (UTC)
most of such images don't comply with MOS:DECOR and should be removed at sight, which is still there, and I've stopped trying to add images to navboxes since. -- Lord Belbury ( talk) 19:20, 11 September 2022 (UTC)
I've gotten to the point where I'm implementing plainlist as TemplateStyles (see MediaWiki talk:Common.css/to do#Plainlist for details) and I've done some work on Navbox to support it, since Navbox mentions the class. The consolidated diff is this change.
Part one of the change makes it so that when Navbox sees the class plainlist
in one of its class parameters (and later, hlist
, when I'm to that point), it will emit plainlist TemplateStyles inside the navbox-styles
div. I hope this will be a fairly limited function for this module in the interest of limiting how much this module needs to know about arbitrary styles as basically a big workaround for how many uses of this module invoke the raw list class, but it could be extended to arbitrary TemplateStyles classes with consensus. A version of it has been deployed at
MediaWiki wiki for a while. The test case at
Template:Navbox/testcases#Horizontal/plain lists should give an idea of what happens.
Part two of the change is something I've had on my mind for a bit. Right now,
phab:T303378 happens: in brief, MobileFrontend removes initial definitions of TemplateStyles if they're found there (as well as later references, but those are not an issue as they become <link>
), at least in the mainspace (my personal test case page doesn't work any more because MobileFrontend seems to have stopped removing the div there entirely, at least in user space). The second change finds TemplateStyles strip markers and moves them to the navbox-styles
div so that Navbox can guarantee styles haven't disappeared from mobile. (As a result, I have to remove nomobile
from that div.) While Navbox particularly doesn't have a lot of worry about it (
Module:Military navigation is probably the large exception in non-wide mode which most-often appears near the tops of articles; it should probably be using
Module:Sidebar), I also plan to implement this in
Module:Sidebar, which currently does appear early in the document in most cases. I'm asking for someone to take a look and see if there's another way this could be done more efficiently than find_hiding_templatestyles()
does now. (I am pretty sure I cannot avoid gsubbing the arg as this would introduce the literal same strip token twice.)
This second part is demonstrated at Template:Navbox/testcases#Save the TemplateStyles.
I'd like to entertain adding one more change (cc @ Frietjes) which is the change discussed earlier regarding sanitizing the inputs to the style parameters for Navbar. That was in the context of Template talk:Navbox/Archive 23#i18n and TemplateStyles improvements. It would be the reversion of this removal from the sandbox. We had not deployed it for some reason I don't know and I think it would be a benefit.
There's probably a fourth change which should happen in the near term, which is getting all the rest of the styles out of the module and into the TemplateStyles page. You see a few of them there in the output of the testcases for change 2. Izno ( talk) 00:48, 15 December 2022 (UTC)
@ Izno: I would expect these to give the same result
but they don't. we should either fix the css order, or add a tracking category to find/fix these? Frietjes ( talk) 20:05, 5 January 2023 (UTC)
:css('width', args[cfg.arg.groupwidth] or '1%')
below the other declarations on the cell. (I don't understand why the ordering there is as it is or why groupCell is there a second time.)|groupwidth=
is set, width:100%
is omitted from the adjacent list cell. if you put the two examples in
Special:ExpandTemplates you will see the difference. by "change 4" in
#TemplateStyles for plainlist, I am assuming you mean "extractcolor" for passing the color to navbar? if so, yes, we should add that to reduce unnecessary css in the navbar. it would also be fun to clean duplicate css (e.g., "background:white; background:black;" -> "background:black;") but I am not sure if it's worth the effort.
Frietjes (
talk) 18:20, 6 January 2023 (UTC)Not sure this is worth fixing or can be fixed, but we came across a formatting issue. The following code:
{{Navbox | title = [[Barrie]] | below = '''[[List of municipalities in Ontario]]''' * [[:Category:Barrie|Category]] }}{{Authority control|qid=Q4863550}}
looks like this:
You'll see the problem with the formatting in the authority control template spread over 5 lines — Martin ( MSGJ · talk) 08:12, 14 February 2023 (UTC)
The initial visibility seems to be stuck in the expanded state, as seen in articles with multiple navboxes (e.g. articles
Safeway,
Star Wars, etc). Forcing the parameter with |state=collapsed
appears to do nothing, as multiple navboxes are still displayed fully expanded; the default autocollapsed is similarly ignored. I'm viewing the pages in desktop mode at 90% zoom (because at 100% zoom,
Reflist no longer autodivides into columns). —
CJDOS, Sheridan, OR (
talk) 12:28, 6 April 2023 (UTC)
This module has a mistake at line 143 (:attr('id', argscfg.arg.title and nil or mw.uri.anchorEncode(argscfg.arg.above]))
); this line attempts to output nil
if args[cfg.arg.title]
is truthy and otherwise mw.uri.anchorEncode(argscfg.arg.above]))
, but because nil
is falsy, the or
always triggers, and as such the line always short-circuits to :attr('id', mw.uri.anchorEncode(argscfg.arg.above]))
. {{
Lemondoge|
Talk|
Contributions}} 00:37, 13 April 2023 (UTC)
x and nil or y
is (x and nil) or y
which is nil or y
which is y
. I remember trying to handle this operation somewhere—that is, trying to find a clean way of making :attr(...)
add an attribute if a certain condition applied, but otherwise add nothing. I can't find what I did and don't have any suggestions at the moment.
Johnuniq (
talk) 07:54, 13 April 2023 (UTC):attr('id', !argscfg.arg.title and mw.uri.anchorEncode(argscfg.arg.above]) or nil)
:attr('id', (not argscfg.arg.title]) and mw.uri.anchorEncode(argscfg.arg.above]) or nil)
) {{
Lemondoge|
Talk|
Contributions}} 13:49, 17 April 2023 (UTC)Is it possible to change the navbox so that the show/hide option has sufficient colour contrast in cases where the navbox uses a non-standard background colour? There are many navboxes where it is hard to see it, for example with {{ Everton F.C.}}, where it would be helpful to either have a different text colour as has been done for the VTE links and title, or for show/hide to be displayed within a separate white/pale background. EdwardUK ( talk) 00:19, 25 April 2023 (UTC)
mw-collapsible
class rather than
Module:Navbox. But have a look at how refs are handled by
Module:Episode table, see for example the last two column heders of
Doctor Who (season 1)#Serials.This is both a question, and a note to self: we already have the ability to have a navbox which can either be used stand-alone in an article, or be transcluded as a child navbox of another nav template and work appropriately in both guises, but imho the feature is underused because the how-to isn't documented, and people aren't aware of the possibility. Does anyone know if there is a standard or conventional way already in use to format such a double-duty navbox? If so, we could just describe that. Either way, something should be added to the doc about it imho, because it is a very useful feature, but would probably be difficult for the occasional template coder to figure out on their own.
I think we could cover it in a new section, probably a subsection of Template:Navbox/doc § Child navboxes called "Transclusion of child navbox" or some such. For a live example in the wild, see French navbox Modèle:Palette Shoah en France (wd-linked to our Template:Holocaust in France, which does not use the feature) which has two child navboxes ( */Victimes and */Survivants), each of which may stand alone as a nav template, or be transcluded in another one. As nothing new needs to be created to do this, it's exclusively a documentation issue to help those who wish to take advantage of the feature. In that regard, this is a "note to self", or to anyone else who feels like tackling it in the doc, as I have no idea when I'll be able to get back to it and wanted to record it here. Mathglot ( talk) 19:27, 28 April 2023 (UTC)
Please, please, it drives me close to tears with frustration every time I'm driven to the point of desperately changing every setting in my profile to no avail just to try to find a way to avoid the misery of switching my browser to desktop view, changing the URL to match, fiddling around with zooming and diagonal scrolling and everything to try to be able to click on the links, and then switching back to mobile to make the linked article actually readable which guarantees I'll have do the same thing again in ten minutes, every time I try to use a group of articles connected by navbox, or even every time an article seems like it might have one since there's no indication. What is the purpose of this nightmare? To avoid some relatively vastly less significant "problem" like horizontal scrolling or weird formatting? You'll notice that the forced desktop/mobile switching still involves the former, so you haven't even managed that. Whose terrible idea was this? Elliefint ( talk) 01:36, 3 June 2023 (UTC)
The redirect Template:Navboxrugby has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2023 July 5 § Template:Navboxrugby until a consensus is reached. SWinxy ( talk) 18:40, 5 July 2023 (UTC)
I was thinking about The Template Transclusion Check earlier today, and wondered if there was a way to enable (opt-in, of course) a tracking cat in the navbox directly to check if the page a template is transcluded on is included in the navbox? I feel like I've seen similar things before in other modules, but if it's not possible that's fine I guess.
For example, a navbox {{ example}} does not link to Example but that article transcludes the template. I was thinking this might be useful for "squad" navboxes where the navbox links may change but the transclusions often do not get updated to match. Primefac ( talk) 09:35, 24 August 2023 (UTC)
This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 20 | Archive 21 | Archive 22 | Archive 23 | Archive 24 |
Hi there! I come here from Template_talk:Taxonbar#Making_Taxonbar_mobile-friendly_and_serve_half_of_all_Wikipedia_readers. As you may be aware, many navboxes are unusable on mobile and break the reading experience and as a result are removed by brute force from the mobile site.
This was meant to be a short term solution, but as with most short term solutions has become long term (see phab:T124168. I'm keen to make steps to rectify this beginning with the Template:Taxonbar, however I need a slight adjustment here to allow me to do this.
My hope here is to provide a general solution that can be applied to other templates.
Any element with the `navbox` class will be removed from the HTML on mobile, so to workaround this issue and allow experimentation in the area, a temporary parameter is needed that will allow us to use a different class to e.g. `navbox-experimental`. Feel free to name this parameter/class anything that makes sense. It could also be mobile=1 and `navbox-mobile-friendly` for example. The important thing is the `navbox` class should not be added.
e.g. proposed change:
local nav = res:tag('div') :attr('role', 'navigation') :addClass('navbox') :addClass(args.navboxclass)
to
local nav = res:tag('div') :attr('role', 'navigation') :addClass(args.experimental ? 'navbox-experimental': 'navbox') # not sure if this is valid Lua code but hopefully it's clear what I'm trying to do here. The class should be navbox-experimental when the flag is set. :addClass(args.navboxclass)
Is this possible? If so I promise to report back when I have something cool to show. Jdlrobson ( talk) 23:24, 24 November 2020 (UTC)
I noticed that this template uses the title of the navbox as an ID (:attr('id', mw.uri.anchorEncode(args.title))
). However, it cannot be assumed that these IDs will always be unique, which creates invalid HTML. For an example of this, see the article
Madame Nhu, which has a section titled
Buddhist crisis, as well as a navbox
Buddhist crisis. The fact that navboxes are usually present on related subjects makes such occurrences likely. I propose that when the ID is created, that it be prefixed with "navbox_" so it doesn't clash with any section headers or user-added anchors.
Opencooper (
talk) 17:01, 17 December 2020 (UTC)
document.getElementById("Buddhist_crisis")
on the Nhu page and you'll only get the header). Currently I see the following inline style being applied: font-size:114%; margin:0 4em
. Given that eventually the goal is to move inline styles to
TemplateStyles, this might end up happening inadvertently.When specified on HTML elements, the id attribute value must be unique amongst all the IDs in the element's tree(note, "must"). Given that we could make our HTML valid just by prefixing the ID, I think this should be addressed. Opencooper ( talk) 17:39, 17 December 2020 (UTC)
Using the "|groupwidth = #em " parameter appears to force extra whitespace and widen the group column of a subgroup, but is there a way to force the column to be narrower? I am asking because a long group name can force extra whitespace into all of the other group names. I can insert <br /> line breaks manually to adjust this, but I was wondering if there is a way to let auto-formatting take care of that via a fixed groupwidth. - 2pou ( talk) 19:54, 17 December 2020 (UTC)
|groupstyle=width:8em;white-space:normal;
should do it, or whatever width is appropriate. Thanks!
Plastikspork
―Œ(talk) 14:57, 18 December 2020 (UTC)
Inside the template Template:Trade unions in Myanmar navbox for list2= item, I am forced to put something there, otherwise even the group2 won't show. Does anyone have a work around, besides for empty/invisible string? Shushugah ( talk) 21:40, 25 February 2021 (UTC)
|list1=
, having what are currently your "groups" under * and all of the values in "list1" having ** indentation. That will still give you the necessary splits without having to bodge things up.
Primefac (
talk) 15:28, 26 February 2021 (UTC)This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
I think that |status=
would be a decent alias for the existing parameter |state=
. Or at least, this seemed like an intuitive option
to me, here; and templates should be more user friendly if possible. Now I don't know enough about template syntax to know what needs to be done, so asking nicely here in case somebody with more of a clue can help.
RandomCanadian (
talk /
contribs) 14:18, 26 March 2021 (UTC)
Would it be possible to set a preference or some CSS so that navboxes and their collapsed sections are all visible to me by default? NemesisAT ( talk) 12:01, 9 May 2021 (UTC)
style=""
attribute of table rows to add or remove the declaration display: none;
. --
Redrose64 🌹 (
talk) 19:51, 9 May 2021 (UTC)
The template documentation says of its image field that "Typically it is purely decorative"... yet MOS:DECOR says "Icons should serve an encyclopedic purpose and not merely be decorative." Should the documentation reflect that, and discourage images that only add decoration? If so, where's the line drawn for what's "decorative"?
I had the policy pointed out to me by someone removing a picture of a potato from Template:Potato dishes, which is maybe fair enough, but that kind of usage seems fairly common across navbox templates. -- Lord Belbury ( talk) 17:59, 12 January 2021 (UTC)
They should provide additional useful information on the ... subject, serve as visual cues that aid the reader's comprehension, or improve navigation.is good advice. -- Michael Bednarek ( talk) 12:10, 22 January 2021 (UTC)
Would it be possible to make this module more localization friendly? Given that other wikis use it, it would be great if you could specify localized parameter names (and values like "autocollapse", "collapsed", "expanded", "plain", "off" etc.) so that they could be used alongside the original, English ones. – Srđan ( talk) 09:56, 5 April 2021 (UTC)
changer
is a function and code
is set as its parameter when changer
is called. That occurs in the final gsub
which calls the function for each match of REGEX_MARKER
. That part of the module is extremely tricky, good luck!Re needsHorizontalLists
and your FIXME: I don't follow. The original code adds the tracking category
Category:Navigational boxes without horizontal lists if parameter listclass is not one of the named classes (plainlist, hlist, etc.); same with parameter bodyclass. I guess you know the module wouldn't work at the moment because it would try to index a nonexistent variable (list_classes
).
Johnuniq (
talk) 07:11, 17 May 2021 (UTC)
{{
•}}
template, which was very bad for accessibility. Back in November/December 2011 we decided to sort this out, with edits
like this. The category was used to find out what still needed fixing. WOSlinker was heavily involved. --
Redrose64 🌹 (
talk) 20:08, 17 May 2021 (UTC)You are invited to join the discussion at Wikipedia:Village pump (proposals) § WikiProject links in navigational templates. -- Trialpears ( talk) 16:02, 8 July 2021 (UTC)
Hello. I added a navbox to Web testing, with no state, so I assume it is defaulting to autocollapse. Interestingly, it is choosing to fully collapse, despite there being no other navboxes on the page. Any idea why? Is this expected behavior? Thanks. – Novem Linguae ( talk) 06:49, 14 May 2021 (UTC)
{{
multiple issues}}
; the two templates that it encloses have no bearing on the matter. --
Redrose64 🌹 (
talk) 17:40, 14 May 2021 (UTC)
{{
Ambox}}
which does the work, so this doesn't happen? --
Michael Bednarek (
talk) 00:38, 15 May 2021 (UTC)
Hi! I am using this template on my MediaWiki site and it's in the default Template namespace (10), however, I also have an additional namespace for templates (4010), the site is configured to allow everyone to edit 4010, but not 10 (which is reserved for synchronized from latest versions of widely used templates). I noticed the V T E links at top-left corner of the navbox links to Template (10) namespace, but I want to configure it to use the custom site 4010 namespace. Is there a way to do this in the {{Navbox...}} wikitext markup? I see the Navbar module appears to have a configuration for the template namespace to use Module:Navbar/configuration#L-4 but I don't think the Navbox template passes this to also be configurable. Jasonkhanlar ( talk) 04:26, 3 May 2022 (UTC)
Thanks to Frietjes and Plastikspork's recent work, the navbox class is no longer used in the wild unless through a template driven by Module:Navbox. As such, I've sandboxed changes (see also Module:Navbox/configuration and Module:Navbox/styles.css) to the module which enable TemplateStyles in the template in preparation for removal from Common.css.
I've also finalized the improvements listed in the localization discussion earlier this year.
The sandboxes are currently 'passing' (behavior is replicated between old and new), so please take a look at those and any favorite navboxes you might have to see if behavior has changed in those as well.
Some potential improvements for this release besides the TODOs in the sandboxes would be:
Other major improvements that could be done but I'm not doing now:
Questions/concerns welcome. Izno ( talk) 01:29, 16 November 2021 (UTC)
pairs
would normally be used but that could read arguments in a strange order conflicting with the comment that the intention is to make reference numbers appear in the right order.
Johnuniq (
talk) 03:37, 16 November 2021 (UTC)
fontstyle = (args.basestyle or '') .. ';' .. (args.titlestyle or '') .. ';background:none transparent;border:none;box-shadow:none;padding:0;'
with something that just extracted the last "color:" parameter. the reason for the background:none transparent;border:none;box-shadow:none;
is to override prior values potentially set in basestyle and/or titlestyle, so we end up sending a bunch of extraneous styles to navbar. but, what we have works, so maybe it's not worth the extra processing.
Frietjes (
talk) 15:10, 16 November 2021 (UTC)
style=";"
which it would be nice not to send if we can avoid it.
Izno (
talk) 02:06, 18 May 2022 (UTC)
sanitizeCSS
with something that extracts the last color from the css
like this. I don't think there is any other css that we should allow for styling the navbar.
Frietjes (
talk) 14:43, 18 May 2022 (UTC)
Some followup!
I have removed the Lua that deals with titlegroup out of the sandbox. The category dragged up nothing in the past month. I'll remove this when I sync the module later.
Separately,
I have adjusted the CSS in the TemplateStyles page due to
this series of edits.
Neveselbert identified that the .navbox th
style, when appended with the .mw-parser-output
and subsequently embedded into a page by TemplateStyles, would override the table header styles of wikitable
tables, which apparently impacted succession boxes in particular.
What this second change means is that handcrafted tables in navboxes will no longer be styled after removal from Common.css some time from now while the TemplateStyles styles are updated by the job queue again. ( Neveselbert, please leave a talk page note in the future with an appropriate ping so that we can get this sorted quicker rather than a month down the road.) I see in the history of MediaWiki:Common.css that this has caused some consternation in the past, but with so few templates, the majority now using at least the same 'external' appearance via the module (i.e., the table header/title), and the fallback being fairly graceful to uncolored embedded tables, I feel comfortable fixing the CSS this way.
There are approximately 900 affected templates, which are now probably mostly using Module:Navbox top and bottom in case anyone should care to fix those in the future. Fixing the 900 templates involves probably 1 or 2 possible paths:
Please let me know if you have significant heartburn. I will leave a pointer about this change at VPT and at Common.css. Izno ( talk) 22:23, 21 December 2021 (UTC)
|titlegroup=
and related parameters have also been removed. :D :D :D
Izno (
talk) 04:42, 10 January 2022 (UTC)
hi everyone. I have a simple formatting question, about our template:navbox. how would I put a simple horizontal bar across the navbox, with some text inside it, to delineate a separate section?
please note, this bar does not need to be the top of a collapsible section; it is simply for visual purposes only, in separating one part of the navbox from the other parts.
appreciate any help. if you want, you can simply link me to an existing navbox which would have this feature. thanks! -- Sm8900 ( talk) 13:47, 16 June 2022 (UTC)
<hr />
tag before the |groupn=
parameter. --
Redrose64 🌹 (
talk) 14:41, 16 June 2022 (UTC)I have learnt in another discussion that there was a deliberate decision by the developers that Navbox is not supposed to be displayed on mobile devices, because they don't work properly. But the problem slowly increases as the percentage of mobile users has reached 65% of pageviews and even more critical as the Premier League is affected. Imagine a premier league match is streamed on mobile devices with only one team visible because the other team doesn't work properly. {{ Tottenham Hotspur F.C.}}, {{ West Ham United F.C.}}, {{ Manchester United F.C.}}, {{ Chelsea F.C.}}, {{ Liverpool F.C.}} and all the others are beautiful creations based on hard work using Navbox but they are invisible on mobile devices. No substitute is available on the template bench of Wiki for the incomplete {{ navbox}}. How can we kick off a new discussion to vote for the development of a technical solution of this problem? Ruedi33a ( talk) 16:38, 30 August 2021 (UTC)
Should we depreciate the use of |image =
parameter from the navbox, as a result for
Wikipedia:Navigation_template#Navigation_templates_are_not_arbitrarily_decorative.
112.204.221.155 (
talk) 16:43, 11 September 2022 (UTC)
most of such images don't comply with MOS:DECOR and should be removed at sight, which is still there, and I've stopped trying to add images to navboxes since. -- Lord Belbury ( talk) 19:20, 11 September 2022 (UTC)
I've gotten to the point where I'm implementing plainlist as TemplateStyles (see MediaWiki talk:Common.css/to do#Plainlist for details) and I've done some work on Navbox to support it, since Navbox mentions the class. The consolidated diff is this change.
Part one of the change makes it so that when Navbox sees the class plainlist
in one of its class parameters (and later, hlist
, when I'm to that point), it will emit plainlist TemplateStyles inside the navbox-styles
div. I hope this will be a fairly limited function for this module in the interest of limiting how much this module needs to know about arbitrary styles as basically a big workaround for how many uses of this module invoke the raw list class, but it could be extended to arbitrary TemplateStyles classes with consensus. A version of it has been deployed at
MediaWiki wiki for a while. The test case at
Template:Navbox/testcases#Horizontal/plain lists should give an idea of what happens.
Part two of the change is something I've had on my mind for a bit. Right now,
phab:T303378 happens: in brief, MobileFrontend removes initial definitions of TemplateStyles if they're found there (as well as later references, but those are not an issue as they become <link>
), at least in the mainspace (my personal test case page doesn't work any more because MobileFrontend seems to have stopped removing the div there entirely, at least in user space). The second change finds TemplateStyles strip markers and moves them to the navbox-styles
div so that Navbox can guarantee styles haven't disappeared from mobile. (As a result, I have to remove nomobile
from that div.) While Navbox particularly doesn't have a lot of worry about it (
Module:Military navigation is probably the large exception in non-wide mode which most-often appears near the tops of articles; it should probably be using
Module:Sidebar), I also plan to implement this in
Module:Sidebar, which currently does appear early in the document in most cases. I'm asking for someone to take a look and see if there's another way this could be done more efficiently than find_hiding_templatestyles()
does now. (I am pretty sure I cannot avoid gsubbing the arg as this would introduce the literal same strip token twice.)
This second part is demonstrated at Template:Navbox/testcases#Save the TemplateStyles.
I'd like to entertain adding one more change (cc @ Frietjes) which is the change discussed earlier regarding sanitizing the inputs to the style parameters for Navbar. That was in the context of Template talk:Navbox/Archive 23#i18n and TemplateStyles improvements. It would be the reversion of this removal from the sandbox. We had not deployed it for some reason I don't know and I think it would be a benefit.
There's probably a fourth change which should happen in the near term, which is getting all the rest of the styles out of the module and into the TemplateStyles page. You see a few of them there in the output of the testcases for change 2. Izno ( talk) 00:48, 15 December 2022 (UTC)
@ Izno: I would expect these to give the same result
but they don't. we should either fix the css order, or add a tracking category to find/fix these? Frietjes ( talk) 20:05, 5 January 2023 (UTC)
:css('width', args[cfg.arg.groupwidth] or '1%')
below the other declarations on the cell. (I don't understand why the ordering there is as it is or why groupCell is there a second time.)|groupwidth=
is set, width:100%
is omitted from the adjacent list cell. if you put the two examples in
Special:ExpandTemplates you will see the difference. by "change 4" in
#TemplateStyles for plainlist, I am assuming you mean "extractcolor" for passing the color to navbar? if so, yes, we should add that to reduce unnecessary css in the navbar. it would also be fun to clean duplicate css (e.g., "background:white; background:black;" -> "background:black;") but I am not sure if it's worth the effort.
Frietjes (
talk) 18:20, 6 January 2023 (UTC)Not sure this is worth fixing or can be fixed, but we came across a formatting issue. The following code:
{{Navbox | title = [[Barrie]] | below = '''[[List of municipalities in Ontario]]''' * [[:Category:Barrie|Category]] }}{{Authority control|qid=Q4863550}}
looks like this:
You'll see the problem with the formatting in the authority control template spread over 5 lines — Martin ( MSGJ · talk) 08:12, 14 February 2023 (UTC)
The initial visibility seems to be stuck in the expanded state, as seen in articles with multiple navboxes (e.g. articles
Safeway,
Star Wars, etc). Forcing the parameter with |state=collapsed
appears to do nothing, as multiple navboxes are still displayed fully expanded; the default autocollapsed is similarly ignored. I'm viewing the pages in desktop mode at 90% zoom (because at 100% zoom,
Reflist no longer autodivides into columns). —
CJDOS, Sheridan, OR (
talk) 12:28, 6 April 2023 (UTC)
This module has a mistake at line 143 (:attr('id', argscfg.arg.title and nil or mw.uri.anchorEncode(argscfg.arg.above]))
); this line attempts to output nil
if args[cfg.arg.title]
is truthy and otherwise mw.uri.anchorEncode(argscfg.arg.above]))
, but because nil
is falsy, the or
always triggers, and as such the line always short-circuits to :attr('id', mw.uri.anchorEncode(argscfg.arg.above]))
. {{
Lemondoge|
Talk|
Contributions}} 00:37, 13 April 2023 (UTC)
x and nil or y
is (x and nil) or y
which is nil or y
which is y
. I remember trying to handle this operation somewhere—that is, trying to find a clean way of making :attr(...)
add an attribute if a certain condition applied, but otherwise add nothing. I can't find what I did and don't have any suggestions at the moment.
Johnuniq (
talk) 07:54, 13 April 2023 (UTC):attr('id', !argscfg.arg.title and mw.uri.anchorEncode(argscfg.arg.above]) or nil)
:attr('id', (not argscfg.arg.title]) and mw.uri.anchorEncode(argscfg.arg.above]) or nil)
) {{
Lemondoge|
Talk|
Contributions}} 13:49, 17 April 2023 (UTC)Is it possible to change the navbox so that the show/hide option has sufficient colour contrast in cases where the navbox uses a non-standard background colour? There are many navboxes where it is hard to see it, for example with {{ Everton F.C.}}, where it would be helpful to either have a different text colour as has been done for the VTE links and title, or for show/hide to be displayed within a separate white/pale background. EdwardUK ( talk) 00:19, 25 April 2023 (UTC)
mw-collapsible
class rather than
Module:Navbox. But have a look at how refs are handled by
Module:Episode table, see for example the last two column heders of
Doctor Who (season 1)#Serials.This is both a question, and a note to self: we already have the ability to have a navbox which can either be used stand-alone in an article, or be transcluded as a child navbox of another nav template and work appropriately in both guises, but imho the feature is underused because the how-to isn't documented, and people aren't aware of the possibility. Does anyone know if there is a standard or conventional way already in use to format such a double-duty navbox? If so, we could just describe that. Either way, something should be added to the doc about it imho, because it is a very useful feature, but would probably be difficult for the occasional template coder to figure out on their own.
I think we could cover it in a new section, probably a subsection of Template:Navbox/doc § Child navboxes called "Transclusion of child navbox" or some such. For a live example in the wild, see French navbox Modèle:Palette Shoah en France (wd-linked to our Template:Holocaust in France, which does not use the feature) which has two child navboxes ( */Victimes and */Survivants), each of which may stand alone as a nav template, or be transcluded in another one. As nothing new needs to be created to do this, it's exclusively a documentation issue to help those who wish to take advantage of the feature. In that regard, this is a "note to self", or to anyone else who feels like tackling it in the doc, as I have no idea when I'll be able to get back to it and wanted to record it here. Mathglot ( talk) 19:27, 28 April 2023 (UTC)
Please, please, it drives me close to tears with frustration every time I'm driven to the point of desperately changing every setting in my profile to no avail just to try to find a way to avoid the misery of switching my browser to desktop view, changing the URL to match, fiddling around with zooming and diagonal scrolling and everything to try to be able to click on the links, and then switching back to mobile to make the linked article actually readable which guarantees I'll have do the same thing again in ten minutes, every time I try to use a group of articles connected by navbox, or even every time an article seems like it might have one since there's no indication. What is the purpose of this nightmare? To avoid some relatively vastly less significant "problem" like horizontal scrolling or weird formatting? You'll notice that the forced desktop/mobile switching still involves the former, so you haven't even managed that. Whose terrible idea was this? Elliefint ( talk) 01:36, 3 June 2023 (UTC)
The redirect Template:Navboxrugby has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2023 July 5 § Template:Navboxrugby until a consensus is reached. SWinxy ( talk) 18:40, 5 July 2023 (UTC)
I was thinking about The Template Transclusion Check earlier today, and wondered if there was a way to enable (opt-in, of course) a tracking cat in the navbox directly to check if the page a template is transcluded on is included in the navbox? I feel like I've seen similar things before in other modules, but if it's not possible that's fine I guess.
For example, a navbox {{ example}} does not link to Example but that article transcludes the template. I was thinking this might be useful for "squad" navboxes where the navbox links may change but the transclusions often do not get updated to match. Primefac ( talk) 09:35, 24 August 2023 (UTC)