Module talk:Sidebar/Archive 6
![]() | 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 1 | ← | Archive 4 | Archive 5 | Archive 6 |
Issue with latest style changes
The addition of the css border-collapse: collapse;
to .sidebar
has caused sidebars to loose the default padding which surrounds the entire sidebar (the 0 2em padding). Take Template:ArbCom sidebar, which has less padding around between the border and the content. Removing this CSS rule returns the padding to normal. Izno, do you have any ideas of how to keep the padding that surrounded the sidebar? By default this padding is there and I presume that other sidebars may have used this padding, which have now had this padding broken. Dreamy Jazz talk to me | my contributions 21:05, 4 August 2021 (UTC)
- That template was overriding that padding. Izno (talk) 21:16, 4 August 2021 (UTC)
- Izno, thanks. I was confused as in inspect element the padding rule on the .sidebar was not greyed out to show as overrided (which I assumed it would be if it was another rule overriding the padding) and as just disabling the rule seemed to fix the issue I didn't think pre-existing rules which applied to other elements were the problem. Thanks, Dreamy Jazz talk to me | my contributions 21:19, 4 August 2021 (UTC)
Template documentation of wraplinks parameter
Is it supposed to turn link wrapping on or off? (Pinging Uzume, who changed the wording in this edit from 2012.) --Paul_012 (talk) 14:44, 8 October 2021 (UTC)
- @Paul 012: All I did was fix the formatting of the documentation. You should probably ask the creators of these Template:Sidebar/doc changes instead: 246309531 and 325612879. The first is by @Sardanaphalus: where the section on "Handling long links" is first introduced. The second is by @Anomie: where the template used is changed from {{longlink}} to {{normalwraplink}}. My change also changed the template reference but only in the initial capitalization which always refers to the same page on Mediawiki references, so my change effectively only targeted fixing English and markup; not any semantic changes. You will also note, all such changes to the documentation, occurred before the conversion from the old template code to the new Scribunto code in 2013, so the documentation is quite likely outdated. —Uzume (talk) 18:28, 8 October 2021 (UTC)
- Based upon the current Module:Sidebar code,
|wraplinks=
causes the content to have the CSS classnowraplinks
added when value of|wraplinks=
is nottrue
. That seems quite different than the current documentation. This functionality was recently changed by @Izno: in 1036808367 and 1002719434 from the original 2013 Module code that was presumably ported from the older Template code (although the changes appear to make it effectively do the same as it used to). I can research the history of the parameter in the old template code too if you like but I am not sure how valuable that is. —Uzume (talk) 18:28, 8 October 2021 (UTC) - I updated the documentation here to swap the paragraphs around (addressing
|wraplinks=
before {{normalwraplink}}) and changing the referenced param value tofalse
, while adding that the {{normalwraplink}} template can be used to wrap specific links while|wraplinks=false
is used. Such a change certainly changes the semantics of the documentation (unlike my earlier referenced change) but methinks it corrects it to be inline with the current functionality. I hope that help by fixes things. —Uzume (talk) 18:28, 8 October 2021 (UTC) - Just to note I saw this and that it is entirely possible I fufed. I will look tomorrow in more detail. Izno (talk) 23:58, 8 October 2021 (UTC)
- The intention of the parameter today, and prior to my edits earlier this year, is to turn link wrapping on (review the version immediately prior to mine). A review of the module at the time of the 2012 edit has
{{#if: {{{wraplinks|}}}|{{#ifeq: {{{wraplinks|}}}|true||nowraplinks}}|nowraplinks}}
which also indicates that "true" turns off nowraplinks. The 2012 edit was accordingly wrong. Izno (talk) 04:16, 11 October 2021 (UTC)- @Izno: Thanks, I reverted my earlier changes and updated the documentation to reflect that here. —Uzume (talk) 07:07, 11 October 2021 (UTC)
- The intention of the parameter today, and prior to my edits earlier this year, is to turn link wrapping on (review the version immediately prior to mine). A review of the module at the time of the 2012 edit has
Vertically center the "[Expand]" button
I've noticed that the "[Expand]" button is not centered vertically like it's header text is to the left of it. It's really annoying to look at.
Could someone please center it? Lectrician1 (talk) 01:46, 20 December 2021 (UTC)
Removing sidebar images as page image
I am not (yet) able to reliably program in Lua without breaking things. Hence, could someone please add a parameter allowing "class=notpageimage" to be added to the sidebar image? Phabricator: [1] This would allow editors to choose whether or not to display the sidebar image as the preview image. Alternatively, we could just automatically add "class=notpageimage" to all sidebar images. Many of them are graphics not useful as previews, or not necessarily appropriate for all of the pages they're used on. Toadspike (talk) 12:14, 28 March 2022 (UTC)
- I intend to do this for all images, but as I expressed on the Phab task, this is nontrivial for me. Izno (talk) 18:49, 28 March 2022 (UTC)
How to override "class=nomobile" to display sidebar in mobile view?
Hi, if to make a sidebar visible in the mobile version of an article (mobile web site), how to override class=nomobile
? I cannot find information about this on the help page.
- Example: In the article Peerages in the United Kingdom the sidebar should be also visible in mobile view. The sidebar-template is {{Peerage}}, which uses the {{Sidebar with collapsible lists}}, which in turn uses {{Sidebar}}.
So how to do? How to pass a parameter from {{Peerage}} to {{Sidebar with collapsible lists}} to {{Sidebar}}? What is the right class-name to make a sidebar visible in mobile view? Thanks a lot! Regards, --W like wiki good to know 14:01, 12 April 2022 (UTC)
- This cannot be overridden and that will not change.
nomobile
is used because the old classvertical-navbox
is already hard-coded to be removed on mobile, but I wanted to change that class name to reflect the name of this module and because it was shorter for the purposes of TemplateStyles, so I addednomobile
as a result. Izno (talk) 17:24, 12 April 2022 (UTC)
List in the below parameter can break the next list
See Template:Sidebar with collapsible lists/testcases#List in the below parameter can break the next list. In example 2, why should omitting the blank line cause breakage of the list bullets? In HTML terms, they're bare <li>...</li>
elements without enclosing <ul>...</ul>
tags. --Redrose64 🌹 (talk) 19:15, 17 May 2022 (UTC)
- I've seen similar behavior (I was fighting with another module the other day over it), and I think it's when an element doesn't get closed the way it's supposed to, so then the parser tries its best to make sense of the remaining soup. I wouldn't be surprised in this case if it's caused by the fact we're using a table, but I don't actually know. Izno (talk) 19:25, 17 May 2022 (UTC)
Should the sidebar image ever be overridden at article level?
Child sidebar templates allow editors to override the "image=" field at the article level, which is sometimes used in place of a lead image (such as http://en.wiki.x.io/w/index.php?title=Ouija&oldid=1067766212). The consequence is that such an article displays with no lead image on mobile, since the mobile view doesn't attempt to display sidebar templates.
Are there cases where it's useful for individual articles to override the sidebar image, or is this an outdated pre-mobile approach which should now be deprecated and removed? --Lord Belbury (talk) 12:18, 26 January 2022 (UTC)
- I think it doesn't make sense to rely on sidebars to generate page images, regardless of whether Module:Sidebar should allow children to change images.
- That said, there's not a lot we can do here to prevent children from changing their images. So long as the direct use of sidebar can change images as on the template's definition page, so too can someone change the direct use to allow passing an image from the indirect use. Izno (talk) 17:54, 26 January 2022 (UTC)
- True. Would it be worth updating WP:SIDEBAR documentation to explicitly say that sidebars should never have article-level images, and that these should always be split out into regular thumbnails above the sidebar, when encountered? (Another problem I encountered today was that not all sidebars support captions below the image, making it impossible to explain what an image is illustrating, while it remains in the sidebar.) --Lord Belbury (talk) 13:59, 17 February 2022 (UTC)
- Never is probably strong, but I have no particular qualms with a similar change. Izno (talk) 18:26, 17 February 2022 (UTC)
- True. Would it be worth updating WP:SIDEBAR documentation to explicitly say that sidebars should never have article-level images, and that these should always be split out into regular thumbnails above the sidebar, when encountered? (Another problem I encountered today was that not all sidebars support captions below the image, making it impossible to explain what an image is illustrating, while it remains in the sidebar.) --Lord Belbury (talk) 13:59, 17 February 2022 (UTC)
I've added a milder do not ... override the "image=" field to illustrate something from the article
to the paragraph about mobile display. --Lord Belbury (talk) 19:32, 17 May 2022 (UTC)
Paramter "state=expanded"
![]() |
Part of a series on |
Peerages in the United Kingdom |
---|
House of Lords |
Hi again, in the template {{Sidebar with collapsible lists}} which uses Template {{Sidebar}} there is (or was?) a parameter named state
– for example see Archive 1 or the use {{Peerage|state=expanded}}
in the article Peerages in the United Kingdom. I cannot find information about this on the help page, also not on Template:Sidebar with collapsible lists/doc. There it is writen | expanded = {{{expanded|}}}
. But if there is Parameter "state", shouldn't it be | expanded = {{{state|}}}
? OR: in the first use {{Peerage|expanded=yes(?)}}
or sthg. similar? Sorry for my poor English, it's not my mother tongue. Thx, --W like wiki good to know 14:27, 12 April 2022 (UTC)
|state=
has never been an argument supported by {{sidebar with collapsible lists}}. You may be confusing it for {{navbox}}, which does accept that parameter. Here|expanded=
is the correct argument as you have identified. Izno (talk) 17:25, 12 April 2022 (UTC)- Fixed. Altanner1991 (talk) 16:24, 28 May 2022 (UTC)
Missing navbar in {{Neolithic}}?
For some reason the v/t/e links are not appearing in {{Neolithic}}. My cursory skim of the source doesn't seem to indicate an obvious reason. Can someone help please? --Joy [shallot] (talk) 08:13, 6 June 2022 (UTC)
- Never mind, I found the reason in another talk page archive - the "name" parameter was missing. Can we document this better? --Joy [shallot] (talk) 08:15, 6 June 2022 (UTC)
- The convoluted "if ... and (args.name or ...) ~= cfg.i18n.title_not_to_add_navbar) then" block should have an "else" sibling that prints some sort of a warning message, whether in the live output or that new box above the edit preview. --Joy [shallot] (talk) 08:19, 6 June 2022 (UTC)
- Why should we warn people about this? Sidebars are not like navboxes which are basically guaranteed to have the relevant parameter. Izno (talk) 15:13, 6 June 2022 (UTC)
- It all comes down to the same thing - no
|name=
, no navbar. In that respect, sidebars are no different from navboxes. --Redrose64 🌹 (talk) 19:52, 6 June 2022 (UTC)
- It all comes down to the same thing - no
- Why should we warn people about this? Sidebars are not like navboxes which are basically guaranteed to have the relevant parameter. Izno (talk) 15:13, 6 June 2022 (UTC)
- We should warn them because it's obfuscated otherwise, it's not intuitive at all, you have to delve into the documentation to understand this quirk. It's bad design. --Joy [shallot] (talk) 08:23, 11 June 2022 (UTC)
Left justified text?
Is there a simple way to use normal left-justified text for the content section? Maury Markowitz (talk) 14:14, 18 July 2022 (UTC)
- @Maury Markowitz, the only way today is to use
|contentstyle=text-align: left
(or the same for|liststyle=
in sidebar with collapsible lists). These parameters are documented in Template:Sidebar#Deprecated parameters. I have considered adding a parameter to support this in the module directly like how the centered text is supported for sidebar with collapsible list titles now. Izno (talk) 06:54, 17 December 2022 (UTC)
Style parameters used in Template:Sidebar person
It appears that about half of the pages in Category:Sidebars with styles needing conversion are there because they use {{Sidebar person}}, which uses a couple of |style=
parameters. If someone who understands the minimal documentation about templatestyles wants to update that template, it will tidy up a bunch of pages at once. – Jonesey95 (talk) 04:15, 14 March 2023 (UTC)
- @Jonesey95, I have done what I can. There is obviously still a parameter there to change the border color of the entire sidebar. That will need to be evaluated -- if a lot of templates are setting that then there should likely be a parameter to permit downstream use of their own TemplateStyles, or removal of the parameter, or perhaps a few choice colors added in this template for use downstream and then the general selection of a color removed. (I have no strong preference.)
- On a general note, I have been thinking about whether this category is the best use of anyone's time, since I'm increasingly of the belief that this template should be deprecated for use in the mainspace entirely. I don't want to waste people's time converting to use TemplateStyles.... Izno (talk) 20:20, 31 May 2023 (UTC)
Headings misaligned with list titles
Support for plainlist TemplateStyles and mobile disappearing styles
I've made some changes to the module sandbox here that reflect changes made to Module:Navbox/sandbox and which I've started a discussion at Template talk:Navbox#TemplateStyles for plainlist. These changes are describe in parts 1 and 2 there. If you have questions, please feel free to discuss there. Izno (talk) 23:40, 16 December 2022 (UTC)
- Hi, Izno. Thank you for your work on the CSS/TemplateStyles refactoring. Are edits such as Special:Diff/1157915259 useful with regards of this effort?
- I see that Module:Sidebar has support for adding the TemplateStyles based on parameters (
|contentclass=
in the case of {{Atomic radius}}). Will functionadd_list_styles
be eventually removed from Module:Sidebar (assuming all relevant places are replaced with explicit calls to {{plainlist}} et al.)? Or isadd_list_styles
and related code for adding TemplateStyles expected to be left in the module "forever"? —andrybak (talk) 19:57, 31 May 2023 (UTC)- @Andrybak, it's probably not much of a win, if a win at all, today, to make swaps like that. I did do that for a few sidebars several years ago, but having to deal with the hundreds of thousands of navigation templates (Module:Sidebar and Module:Navbox, and Module:Infobox too) made it not a winning strategy to me when there are other much larger gains to be had. Right now, if there is a loss, it's that the addition of plainlist/hlist styles to a page would become slightly less deterministic. Izno (talk) 19:59, 31 May 2023 (UTC)
- I'm confused. I think I don't understand the layout/formatting of the page MediaWiki talk:Common.css/to do. For example, {{Infobox Cyrillic letter}} was still listed for plainlist. However, Special:Diff/1157920338 seems very similar to the aforementioned Special:Diff/1157915259. What am I missing? —andrybak (talk) 20:22, 31 May 2023 (UTC)
- My link to the to do page was to indicate there is higher-value work to be done on other things than the pretty-mechanical/low-value change that adds plainlist/hlist templates and eventually removes the checking code from the module.
- Your infobox cyrillic letter change looks fine (though now-reverted and a full page protection on top of that unrelated to your efforts). There are more painful conversions for infoboxes which is why I added the checking code in Module:Infobox as well (think: it is trivial to make an infobox where the row disappears with a basic parameter and a class in the row class rather than putting an if block in with a template).
- The parts of the to do list that should be worked are the ones not under the "done" section. :) Izno (talk) 07:40, 1 June 2023 (UTC)
- I'm confused. I think I don't understand the layout/formatting of the page MediaWiki talk:Common.css/to do. For example, {{Infobox Cyrillic letter}} was still listed for plainlist. However, Special:Diff/1157920338 seems very similar to the aforementioned Special:Diff/1157915259. What am I missing? —andrybak (talk) 20:22, 31 May 2023 (UTC)
- @Andrybak, it's probably not much of a win, if a win at all, today, to make swaps like that. I did do that for a few sidebars several years ago, but having to deal with the hundreds of thousands of navigation templates (Module:Sidebar and Module:Navbox, and Module:Infobox too) made it not a winning strategy to me when there are other much larger gains to be had. Right now, if there is a loss, it's that the addition of plainlist/hlist styles to a page would become slightly less deterministic. Izno (talk) 19:59, 31 May 2023 (UTC)