|
|
| (не показана 1 промежуточная версия этого же участника) |
| Строка 1: |
Строка 1: |
| {{WikiProject banner shell|
| |
| {{WikiProject Templates|template_for_template_maintenance=y}}
| |
| }}
| |
| {{User:MiszaBot/config |archiveheader={{talkarchivenav}} |maxarchivesize=70K |counter=24 |minthreadsleft=4 |minthreadstoarchive=1 |algo=old(120d) |archive=Template talk:Navbox/Archive %(counter)d}}
| |
| {{Central|Module talk:Navbox}}
| |
| {{Archives |auto=long |search=yes |bot=MiszaBot II |age=120 |
| |
| * {{longitem|See [[Template talk:Navbox generic]] for previous discussions.}}
| |
| }}
| |
|
| |
|
| == Make navbox-title links show in dark mode ==
| |
|
| |
| {{edit template-protected|Module:Navbox|answered=yes}}
| |
| [https://en.wikipedia.org/w/index.php?title=Module%3ANavbox%2Fsandbox%2Fstyles.css&diff=1236070189&oldid=1235538544 proposed fix]
| |
|
| |
| The following fix should address the issue described [https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=1236068066#Dark_Mode_Text here]. I do have edit rights but wanted a second opinion before applying these change.
| |
|
| |
| The issue occurs because a mixture of things:
| |
| * We have a well-meaning rule in MediaWiki:Vector-2022.css that makes all links black when a background is detected via inline styles (this corrects the large majority of issues in dark mode so we don't want to remove it)
| |
| * [[mw:Extension:WikimediaMessages]] strips styling from navboxes in a way that clashes with the table rule.
| |
|
| |
| My proposed fix is to do this on the template level.
| |
|
| |
| An alternative I considered was to add another !important rule in [[MediaWiki:Vector-2022.css]] but I think it is preferable that the fix lives in the navbox styles. Hopefully on the long term we can move the color stripping in WikimediaMessages into the Navbox template itself and this will all be easier to follow. <span style="background:white; color: black;">🐸</span> [[User:Jdlrobson|Jdlrobson]] ([[User talk:Jdlrobson|talk]]) 18:57, 22 July 2024 (UTC)
| |
|
| |
| :The 3rd alternative is to resolve the task in Phab that allows us to turn off the dark mode for specific components, and then we can turn that one off for navbox. That's something that could take an hour or two tops. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 19:10, 22 July 2024 (UTC)
| |
| ::Right this is what I am talking about when I say "on the long term".
| |
| ::we are looking at a least a month for a fix for that to go into production given web team's other commitments. There are far more important issues that need addressing unfortunately.
| |
| ::It would be nice to have a short term fix in the mean time. We can reference the phabricator ticket in an inline comment and I can make sure it gets undone whenever that ticket gets worked on. <span style="background:white; color: black;">🐸</span> [[User:Jdlrobson|Jdlrobson]] ([[User talk:Jdlrobson|talk]]) 21:30, 22 July 2024 (UTC)
| |
| :::Am I reading the code correctly, inferring that the change applies only to links in the navbox title? If so, what is the fix for visited links in the navbox body, which are also showing as gray-on-black for me? I could be reading the code wrong. – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 00:43, 23 July 2024 (UTC)
| |
| ::::Can you give an example page @[[User:Jonesey95|Jonesey95]]? But yeh this is only for navbox title as that was the only issue I was aware of.
| |
| ::::If there are other elements these could use the same rules, substituting th.navbox-title for the relevant selector. <span style="background:white; color: black;">🐸</span> [[User:Jdlrobson|Jdlrobson]] ([[User talk:Jdlrobson|talk]]) 17:59, 23 July 2024 (UTC)
| |
| :::::It looks like my memory is wrong. I went back to {{tl|Soulfly}}, and it is only the top navbar title and the subhead title where visited links are turning gray instead of purple. Carry on. – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 18:03, 23 July 2024 (UTC)
| |
| ::::::In what I assume is a related CSS problem, on {{tl|Malawian roads}}, I see links to articles as blue or red if non-existent in light mode, but only blue in dark mode. For example, [[M26 road (Malawi)]] does not exist, but shows up as blue in dark mode. -- [[User:Beland|Beland]] ([[User talk:Beland|talk]]) 20:36, 2 August 2024 (UTC)
| |
| :::::::FTR, previewing {{tl|Malawian roads}} and changing it to point to {{tl|Navbox/sandbox}} did not fix the red link color problem. -- [[User:Beland|Beland]] ([[User talk:Beland|talk]]) 20:41, 2 August 2024 (UTC)
| |
| :[[File:Red information icon with gradient background.svg|20px|link=|alt=]] '''Not done for now:'''<!-- Template:ETp --> I've fixed this in the template at issue based on upstream support for self-link to Vector-2022/Minerva.css. If there are others (I suspect there may be), we can discuss those then. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 17:39, 5 September 2024 (UTC)
| |
| ::Thanks for the fix! That looks good on {{tl|Malawian roads}} now. -- [[User:Beland|Beland]] ([[User talk:Beland|talk]]) 05:45, 6 September 2024 (UTC)
| |
|
| |
| == Directly render child navboxes ==
| |
|
| |
| Lots of articles exceed the [[WP:PEIS|post-expand include size]] limit due to navboxes taking up a huge amount of bytes. A lot of this is caused by navboxes that include child navboxes, because nesting a navbox template inside another navbox template causes the inner navbox to be counted twice towards the limit (and if you are using the template instead of the module directly, it actually counts 4x). To alleviate this, I have modified [[Special:Permalink/1237643997|Module:Navbox/sandbox]] to allow child navboxes to be added without having to add an additional template call or module invocation. For example, instead of
| |
|
| |
| <syntaxhighlight lang="wikitext">{{Navbox
| |
| | name = {{subst:PAGENAME}}
| |
| | title = Title
| |
| | list1 = {{Navbox|child
| |
| | group1 = Group1.1
| |
| | list1 = List1
| |
| }}
| |
| | list2 = {{Navbox|child
| |
| | group1 = Group2.1
| |
| | list1 = List1
| |
| }}
| |
| }}</syntaxhighlight>
| |
|
| |
| You could do
| |
|
| |
| <syntaxhighlight lang="wikitext">{{Navbox
| |
| | name = {{subst:PAGENAME}}
| |
| | title = Title
| |
| | list1 = child
| |
| | list1_group1 = Group1.1
| |
| | list1_list1 = List1
| |
| | list2 = child
| |
| | list2_group1 = Group2.1
| |
| | list2_list1 = List1
| |
| }}</syntaxhighlight>
| |
|
| |
| The code only kicks in if the text of list# is the "child" keyword AND at least one parameter is specified that starts with "list#_". The result is a drastically smaller post-expand include size and, in my opinion, easier to read code. Of course, the old method, or a combination of the two, still works, as demonstrated at [[User:Ahecht/sandbox4]]. Any thoughts before I make a formal edit request? <span class="nowrap">--[[User:Ahecht|Ahecht]] ([[User talk:Ahecht|<b style="color:#FFF;background:#04A;display:inline-block;padding:1px;vertical-align:middle;font:bold 50%/1 sans-serif;text-align:center">TALK<br />PAGE</b>]])</span> 20:08, 30 July 2024 (UTC)
| |
|
| |
| :I've thought about doing it similar to this. I think I'd rather see something like <code>list1.1</code> and <code>group1.1</code> which is a little shorter and probably doesn't result in code too different.
| |
| :I'm not totally certain we need to opt in with <code>child</code>, I'm pretty sure this could be done without the additional keyword. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 20:16, 30 July 2024 (UTC)
| |
| ::@[[User:Izno|Izno]] So a child navbox in "list 4" would use <code>group1.4</code>, <code>list1.4</code>, <code>group1style.4</code>, <code>image.4</code>, or would it be <code>group4.1</code>, <code>list4.1</code>, <code>group4style.1</code>, <code>image4</code>, etc? If it's the former, it shouldn't be any more difficult to code, although it doesn't have the same natural indentation, and the hierarchical order isn't what most people would expect (although using <code>4.group1</code>, <code>4.list1</code>, etc. fixes that problem). If it's the latter, the code would certainly be more convoluted since some arguments would be delimited, others wouldn't, and the number to extract is in a different place in different variables. It would also make converting existing navboxes more difficult.
| |
| ::You're right that there's no need to opt in with the <code>child</code> keyword -- we could scan the arguments for delimited ones, extract the list number, and add it to <code>listnums</code>. The only reason I included it is that it makes it clearly visible to someone creating or editing a navbox template that that list number is taken, which should make it less likely they'll accidentally add text to both <code>list#</code> and specify parameters for a child. <span class="nowrap">--[[User:Ahecht|Ahecht]] ([[User talk:Ahecht|<b style="color:#FFF;background:#04A;display:inline-block;padding:1px;vertical-align:middle;font:bold 50%/1 sans-serif;text-align:center">TALK<br />PAGE</b>]])</span> 20:58, 30 July 2024 (UTC)
| |
| :::I am slightly more in favour of the <code>list''x''_list''y''</code> styling, as it will make visually distinguishing the groups (especially if they are aligned). [[User:Primefac|Primefac]] ([[User talk:Primefac|talk]]) 11:57, 31 July 2024 (UTC)
| |
| ::::The thing I'm thinking about is that I've seen 3 or even 4 layers of navboxes, so <code>list1_group1_list1_group1_list1_group1</code> gets kind of unwieldy. :) Actually, does the implementation work for the more layers case? [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 15:52, 31 July 2024 (UTC)
| |
| :::::Hrm, good point. [[User:Primefac|Primefac]] ([[User talk:Primefac|talk]]) 16:04, 31 July 2024 (UTC)
| |
| :::::@[[User:Izno|Izno]], [[User:Primefac|Primefac]] The implementation is recursive so it does work with nested lists (I added an example to [[User:Ahecht/sandbox4]]), although it would "only" be <code>list1_list1_list1_group1</code>. The more I think about it, the more I dislike the <code>list1_list1</code> notation (since it's not really a list at that point), and I'm leaning towards either <code>child1_list1</code>/<code>subgroup1_list1</code> as more descriptive or just <code>1_list1</code> as more concise. <span class="nowrap">--[[User:Ahecht|Ahecht]] ([[User talk:Ahecht|<b style="color:#FFF;background:#04A;display:inline-block;padding:1px;vertical-align:middle;font:bold 50%/1 sans-serif;text-align:center">TALK<br />PAGE</b>]])</span> 16:47, 31 July 2024 (UTC)
| |
|
| |
| {{edit template-protected|Module:Navbox|answered=yes}}
| |
| :I've updated the sandbox at [[Special:Permalink/1239318936]] to accept <code>child1_list1</code>, <code>subgroup1_list1</code>, and <code>1_list1</code> notation, as demonstrated at [[User:Ahecht/sandbox4]]. It currently requires either the <code>child</code> or <code>subgroup</code> keywords, but that requirement could be potentially removed in a future update. I also made the function that reads the arguments recursive to keep references in the correct order even when children/subgroups are used.<span class="nowrap">--[[User:Ahecht|Ahecht]] ([[User talk:Ahecht|<b style="color:#FFF;background:#04A;display:inline-block;padding:1px;vertical-align:middle;font:bold 50%/1 sans-serif;text-align:center">TALK<br />PAGE</b>]])</span> 13:53, 8 August 2024 (UTC)
| |
| :{{done}}<!-- Template:ETp --> I went ahead and implemented this. Hopefully I didn't just break 8% of Wikipedia! <span class="nowrap">--[[User:Ahecht|Ahecht]] ([[User talk:Ahecht|<b style="color:#FFF;background:#04A;display:inline-block;padding:1px;vertical-align:middle;font:bold 50%/1 sans-serif;text-align:center">TALK<br />PAGE</b>]])</span> 18:03, 16 August 2024 (UTC)
| |
| ::[[:zh:Module:NavboxV2]] has already achieved directly render child navboxes four years ago and integrated with {{tl|Navbox with columns}} / {{tl|Navbox with collapsible groups}} (throuth the {{para|type}} parameter). [[User:Dabao qian|Dabao qian]] ([[User talk:Dabao qian|talk]]) 05:52, 8 September 2024 (UTC)
| |
| :::@[[User:Dabao qian|Dabao qian]] I've consolidated the three templates into [[Module:Navbox/sandbox]]. You can set {{para|type}} (or {{para|1_type}}) to "with columns" or "with collapsible groups". For {{tl|Navbox with columns}} you use "col1_list1" notation for subgroups of the columns. See [[Template:Navbox/testcases#allthreetypes]] for an example. <span class="nowrap">--[[User:Ahecht|Ahecht]] ([[User talk:Ahecht|<b style="color:#FFF;background:#04A;display:inline-block;padding:1px;vertical-align:middle;font:bold 50%/1 sans-serif;text-align:center">TALK<br />PAGE</b>]])</span> 01:14, 2 October 2024 (UTC)
| |
| ::::Okay, that looks like the Chinese version. Set {{para|type}}(default sets to "vertical") to "horizontal" or "vertical_collapsible" to switch {{tl|Navbox with columns}} or {{tl|Navbox with collapsible groups}}. [[User:Dabao qian|Dabao qian]] ([[User talk:Dabao qian|talk]]) 13:10, 2 October 2024 (UTC)
| |
| :::::@[[User:Dabao qian|Dabao qian]] The exact keywords that are used can be set in [[Module:Navbox/configuration/sandbox]] as <code>keyword.with_collapsible_groups</code> and <code>keyword.with_columns</code>. I chose "with columns" and "with collapsible groups" because we've been using the names {{tl|navbox with columns}} and {{tl|navbox with collapsible groups}} on the English Wikipedia for the past 7 years so those terms are more familiar than "horizontal" and "vertical_collapsible" (plus it allows replacing {{tl|navbox with columns}} with {{ml|navbox|with columns}}). <span class="nowrap">--[[User:Ahecht|Ahecht]] ([[User talk:Ahecht|<b style="color:#FFF;background:#04A;display:inline-block;padding:1px;vertical-align:middle;font:bold 50%/1 sans-serif;text-align:center">TALK<br />PAGE</b>]])</span> 17:04, 2 October 2024 (UTC)
| |
| ::::::I've copied this module to zh-yuewiki (see [[:yue:Module:NavboxV2]]) and modified for compatibility with [[:zh:Module:NavboxV2]]. But how to allow both {{para|1_border}} and {{para|list1|''[child/subgroup]''}} can be used? [[User:Dabao qian|Dabao qian]] ([[User talk:Dabao qian|talk]]) 17:18, 2 October 2024 (UTC)
| |
| :::::::@[[User:Dabao qian|Dabao qian]] You shouldn't ever need to use {{para|1_border}}. If you use {{para|list1|subgroup}}, the module automatically sets {{para|1_border|subgroup}} without you having to specify it (it also automatically sets {{para|1_navbar|plain}}). You can still use the old method as well, so <syntaxhighlight lang="wikitext" inline>{{#invoke:NavboxV2|navbox|list1=subgroup|1_list1=List 1}}</syntaxhighlight> should produce the same result as <syntaxhighlight lang="wikitext" inline>{{#invoke:NavboxV2|navbox|list1={{#invoke:NavboxV2|navbox|border=subgroup|navbar=plain|list1=List 1}}}}</syntaxhighlight>. <span class="nowrap">--[[User:Ahecht|Ahecht]] ([[User talk:Ahecht|<b style="color:#FFF;background:#04A;display:inline-block;padding:1px;vertical-align:middle;font:bold 50%/1 sans-serif;text-align:center">TALK<br />PAGE</b>]])</span> 00:48, 8 October 2024 (UTC)
| |
| :As the author of NavboxV2, I finally see that enwiki also has the problem of Navbox overload which is similar to zh and needs a solution. I feel touched. (LOL)
| |
| :Regarding the parameter mode issue:
| |
| :*For the separator, I chose "-" (short dash), and you chose "_" (underscore). This is a personal choice and I don't plan to make compatibility here. It mainly involves the uncertainty of parameter detection (both dashes and underscores need to be detected at the same time), some hard-coded problems (some codes only use dashes as the value of the incoming parameter search), and my laziness;
| |
| :*For sub-body detection, I don't use <code>listN=child</code> because the sub-body detection code of the <code>border</code> parameter can be reused, and the uncertainty of parameter detection can be avoided as same time (it is necessary to guess whether the "child" of <code>listN=child</code> is the mark value of sub-body, or the ordinary list content value. And the former also requires more sub-body parameter detection code);
| |
| :*For regarding adding "list"-like parameters, such as "child" and "subgroup", similarly, since most of the code structure of {{tl|Navbox}} is copied, the code position of the original "list" value, the parameter name is just "list", so keep it simple and don't add too much additional input uncertainty.
| |
| :The code of NavboxV2 is not integrated into Navbox, but a new template is created. This is because I am not a local administrator and cannot update the code of Navbox at will. In addition, the new template can be debugged and fixed the code at any time to avoid affecting the normal operation of Navbox.
| |
| :I'll keep an eye on your work and try to see if there's anything interesting I can draw on. --[[User:Cwek|Cwek]] ([[User talk:Cwek|talk]]) 09:35, 9 October 2024 (UTC)
| |
|
| |
| == Dark mode white border ==
| |
|
| |
| In dark mode, for all navboxes, the border looks like this: [[File:En.wikipedia.org Template talk-Navbox 2024-08-07.png]]<br/>Is there a way to fix this so that the borders appear correctly? It's a minor thing but one that affects a lot of articles.<span id="Qwerfjkl:1723030360530:Template_talkFTTCLNNavbox" class="FTTCmt"> — [[User:Qwerfjkl|<span style="background:#1d9ffc; color:white; padding:5px; box-shadow:darkgray 2px 2px 2px;">Qwerfjkl</span>]][[User talk:Qwerfjkl|<span style="background:#79c0f2;color:white; padding:2px; box-shadow:darkgray 2px 2px 2px;">talk</span>]] 11:32, 7 August 2024 (UTC)</span>
| |
|
| |
| :The white borders is used to distinguish odd/even list rows. [[User:Dabao qian|Dabao qian]] ([[User talk:Dabao qian|talk]]) 05:57, 8 September 2024 (UTC)
| |
|
| |
| ::They shouldn't be visible borders, though, specially not bright white like that. The borders should be rendered the same color as the other grey borders. This can be fixed in the CSS rules for dark mode, were someone with the ability to edit it could do so. '''[[User:Down10|Down10]]''' <sup>[[User talk:Down10|TA]][[Special:Contributions/Down10|CO]]</sup> 07:52, 8 October 2024 (UTC)
| |
|
| |
| == Mobile visibility ==
| |
|
| |
| Hello all,
| |
|
| |
| I didn't want to be too [[WP:BOLD]] and remove the information stating that the template is not visible on mobile, although I checked just a second ago and it is. I also checked the Phab report linked in the header as part of an edit to another page and it seems that the issue has been at least partially resolved.
| |
|
| |
| If someone would be willing to update the page to reflect recent changes, or alternatively tell me that I'm completely wrong lol, let me know!
| |
|
| |
| [[User:JuxtaposedJacob|JuxtaposedJacob]] ([[User talk:JuxtaposedJacob|talk]]) | :) | 01:10, 18 October 2024 (UTC)
| |
|
| |
| :Navboxes are not generally visible on mobile. <span style="border-radius:2px;padding:3px;background:#1E816F">[[User:Remsense|<span style="color:#fff">'''Remsense'''</span>]]<span style="color:#fff"> ‥ </span>[[User talk:Remsense|<span lang="zh" style="color:#fff">'''论'''</span>]]</span> 01:28, 18 October 2024 (UTC)
| |
| ::Fascinating, I can see the ones on my userpage on mobile, but not the ones in article space.
| |
| ::Thanks!
| |
| ::[[User:JuxtaposedJacob|JuxtaposedJacob]] ([[User talk:JuxtaposedJacob|talk]]) | :) | 04:23, 18 October 2024 (UTC)
| |
| :They are (now) visible outside of mainspace, so there probably should be a refinement to provide correct information. [[User:Izno|Izno]] ([[User talk:Izno|talk]]) 18:13, 18 October 2024 (UTC)
| |
