Template talk:Navbox

message: It seems this module adds the autocollapse class. autocollapse is defined in MediaWiki:Common.js. It's unclear to me why it doesn't add mw-collapsed instead which is part of MediaWiki?Edit: just noticed this note in Common.js: "deprecated Since MediaWiki 1.20: Use class="mw-collapsible" instead which is supported in MediaWiki core. Shimmable since MediaWiki 1.32"Edit2: I'm not reading right and I get it now. For reference: collapsible is deprecated in favor of mw-collapsible and collapsed is deprecated in favor of mw-collapsed. The function of autocollapse in common.js is specifically to collapse the element only if more than one collapse element exists on the page. So if a page has only one navbox and no other collapsible elements, the navbox will be uncollapsed by default. But if another navbox is added, both will be collapsed by default.While I see why this can be desired, I think it's also rather confusing, making navboxes act differently depending on the presence of other elements on the page. — Alexis Jazz (talk or ping me) 20:27, 4 September 2023 (UTC)
replies: text: FWIW, it's how they have worked for a long time. I'm not saying it's good or bad. – Jonesey95 (talk) 22:36, 4 September 2023 (UTC)
replies: text: Jonesey95, I was testing some stuff and found a navbox to not collapse by default on one article, but collapse by default on another. I thought it was a bug or oversight in something I wrote, only to finally figure out what "autocollapse" actually does.I suppose we could discuss whether navbox should use autocollapse or not. From what I understand, if an article has one navbox and one collapsible list is added somewhere in the infobox with the autocollapse class that'll also cause the navbox to autocollapse.Having the navbox as the only collapsible item uncollapsed by default would sometimes make sense. But on a short stub it would look a bit silly. My thought is that editors would be best suited to decide on a per-article basis which (if any) navboxes should be uncollapsed by default. — Alexis Jazz (talk or ping me) 00:57, 5 September 2023 (UTC)
replies: text: IMO the autocollapsing is a generally a good thing if more than one navbox is present. I wasn't aware that this behaviour is also influenced by other collapsible elements in the body, which are discouraged. I suppose we have to leave it to editors to decide whether overriding  is appropriate sometimes (e.g. having one navbox closely related to the the article's subject and several others only loosely related). -- Michael Bednarek (talk) 01:35, 5 September 2023 (UTC)
replies: text: , if I understand your desire correctly: any navbox can be expanded in a given article by adding  to its transclusion. You can see this in action at Wikidata#External links or U.S. state#External links. If it doesn't work for a given navbox template, the template's code might need a bit of adjustment; sometimes people delete the standard collapsing code. If you want or need a demo, link to an article and suggest a navbox to be expanded. – Jonesey95 (talk) 03:22, 5 September 2023 (UTC)
replies: text: Jonesey95, thanks, I think I understand how it works. What mostly bothers me is that this template is essentially depending on the code in Common.js, which is kinda odd and makes it more confusing for any other project to import this template/module. It also confused me when I was testing navboxes on the mobile site where Common.js doesn't get loaded. I've resolved that issue though.I think I'd personally support changing the default from "autocollapse" to "collapsed", but unless others feel the same I don't expect it to happen. — Alexis Jazz (talk or ping me) 03:47, 5 September 2023 (UTC)

text: We could of course just change this to be something like. If this is the main namespace, then if there is one navbox have it open, but if there is more than one navbox, collapse them all. and get rid of the entire old auto collapse behaviour. The one problem I see is that I'm not entirely sure where else auto collapse is used. —TheDJ (talk • contribs) 08:26, 27 September 2023 (UTC)
replies: text: TheDJ, I'm guessing many editors use autocollapse because they confuse it with mw-collapsed, thinking it just means "always automatically collapse this". I only figured out what autocollapse means after analyzing Common.js. If I had no idea it's pretty much guaranteed a new editor has no clue either. (sure it's in the template documentation, but editors often learn by copying existing wikicode) Take a look at :Geographic coordinate system: the navbox has the autocollapse state specifically set as a parameter and the navbox gets collapsed due to the presence of . No way that was the intention of any editor. It was added by an IP editor in Geographic coordinate system (Diff ~675689024) btw. This is largely a running theme when looking at Special:Search/insource:autocollapse. My personal opinion is still that it would be clearer if state=collapsed was the default for navboxes and editors would have to set the parameter state=expanded where appropriate. But that's merely my 2 cents.That being said, changing autocollapse to only react to navboxes would make its behavior a bit easier to understand, more logical and less likely to be triggered accidentally as it is on :Geographic coordinate system. The end result on that article may or may not be desirable, but the presence of  has no bearing on that. — Alexis Jazz (talk or ping me) 15:47, 27 September 2023 (UTC)

text: @TheDJ the other notable location for autocollapse is Template:Sidebar with collapsible lists and probably that one's mother-template-by-time of Template:Collapsible list (which ends up in infoboxes). Izno (talk) 18:17, 7 October 2023 (UTC)

text: Rather late to the party, but I've added an anchor to the state documentation, with the appropriate redirect shortcut WP:AUTOCOLLAPSE, to hopefully help with future confusion. 「ディノ奴千？！」☎ Dinoguy1000 01:09, 16 December 2023 (UTC)
thread_title:  autocollapse vs. mw-collapsed 

message: (For background, see Wikipedia:Help desk#Removing a bullet from a template)
In the example above, a bullet is (incorrectly?) rendered after list 2.1a but not after list 1.1a.  This may be a MediaWiki bug;  shows no bullet after either. LittlePuppers (talk) 23:46, 19 February 2024 (UTC)
replies: text: I don't know if it's the actual cause, but removing the blank line between the list items makes the two appear the same for me in edit preview. List items belonging to the same list shouldn't have a blank line between them, or else the MediaWiki parser will treat them as two separate lists. isaacl (talk) 23:57, 19 February 2024 (UTC)
replies: text: Indeed, that causes them to appear the same, but the intention appears to be subdividing the list: see  for one place this is used (and where this question comes from). LittlePuppers (talk) 00:11, 20 February 2024 (UTC)
replies: text: I see; your naming convention made it seem like the two items belonged to the same list. I don't know which specific section in the navbox you are referring to; could you create a smaller example with real data, or point to the appropriate location to examine? found where to look isaacl (talk) 00:23, 20 February 2024 (UTC)

text: Using the browser HTML debugging tools, I can see that list item 2.1a isn't being surrounded by , so the CSS style rule that suppresses adding the trailing bullet isn't getting applied. I don't know why this isn't being parsed as a list, though. isaacl (talk) 00:50, 20 February 2024 (UTC)
replies: text: Also see WP:LISTGAP. It looks like that navbox starts a new list inside of a list where it says "Discontinued". I think that's just GIGO, invalid list markup, so you should not expect good behavior. The fix is to use proper list markup, I think, maybe by nesting more subgroup navboxes. – Jonesey95 (talk) 01:04, 20 February 2024 (UTC)
thread_title:  Extraneous bullets in lists 

message: You are invited to join the discussion at Template talk:Southern California Intercollegiate Athletic Conference navbox § Night mode compatibility?.  Sdkb talk 19:43, 14 May 2024 (UTC)
thread_title: Discussion on making navboxes compatible with night mode