Module talk:Sidebar/Archive 5
![]() | This is an archive of past discussions about Module:Sidebar. 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 3 | Archive 4 | Archive 5 | Archive 6 |
Stripped-tag errors #2
As I told before the Sidebar module produces a lot of linter errors. That's why I am proposing the following changes:
Change line 99 from
:wikitext('</th></tr>') -- @todo replace this with unclosed again once mw.html gets it
to
:wikitext('</td></tr><tr><td>') -- @todo replace this with unclosed again once mw.html gets it
and change line 165
:tag('th')
to
:tag('td') -- instead of th :css('font-weight', 'bold')
as we did it on the German Wikivoyage.
The main problem was the insertion of child sidebars both to table cells td
(content) and table header cells th
(heading). In line 99 we cannot know if the plain title text is added to td
or th
. That's why a lot of linter errors occur. --RolandUnger (talk) 16:15, 22 November 2017 (UTC)
- RolandUnger, two things: (1) can you provide a link to an example which is generating these linter errors (one from an article is better than a manufactured example)? and (2) can you put your changes in the Module:Sidebar/sandbox? for Module:Infobox, we made this change to have the parent fix the children, since (as you note) it's not possible for the child to detect if the child is being embedded in a th or td cell. assuming that the parent cell is a td (and not a th) is probably the most likely case, but it's not clear to me that is always the case. Frietjes (talk) 17:48, 22 November 2017 (UTC)
- I'm puzzled by the change from th to td, since I don't see an obvious need for that. These are properly th's in the vast majority of cases. --Izno (talk) 17:54, 22 November 2017 (UTC)
- After changing line 165 you can remove line 99. You can see this change both on German Wikivoyage as on English Wikipedia. The main problem is caused by line 99, and programmers like Mr. Stradivarius should know this problem.
- To 1st: It is really difficult to present an example because of 1.7 million "Missing end tag" and 0.6 million "Stripped tags" and the missing opportunity to filter theses errors.
- But I will try to explain the problem: child sidebars were put into a (1) table cell
td
or a (2) table header cellth
. The following code will be produced:(1) <td> a title </th></tr> ... nothing else </td></tr>
- /th has to be ignored because not opened, /td is missing because of closing /tr; /td and /tr have to be ignored because not opened
(2) <th> a title </th></tr> ... nothing else </th></tr>
- Final /th and /tr have to be ignored because not opened
- After these changes we do not have any linter errors caused by Sidebar at German Wikivoyage any longer. Please have a look to a working sidebar on voy:de:Template:Sidebar.
- To 2nd: I put it to the sandbox.
- Additionally, I like to propose the rewriting of the module. First: all sidebars should have table containers, not only the parent one. Then you can neglect the child parameter. The correct drawing can be made with CSS which can be moved to Common.css. Second: you should replace the tables by div tags. With both ideas you can simplify the code. --RolandUnger (talk) 06:18, 23 November 2017 (UTC)
- RolandUnger, (1) I added Category:Pages using sidebar with the child parameter so we can find all the uses and make sure nothing is broken by any changes, (2) many of the subsidebars are using {{subsidebar bodystyle}} to change the outer inline css, (3) a rewrite to use div tags instead of tables was attempted on 3 June 2017, but there were so many problems that it had to be rolled back. basically, you have to have a method for finding/tracking all the places that implicitly assume that sidebar is generating table markup. it's possible to do the conversion and fix all the problems, but you need a method to find/fix all the problems. for example, what was done at Module:Navbox when we added the automatic striping. I agree that having the sitewide css detect that it's a child and style it appropriately would be great, but we would need a method for finding/fixing all the problems. Frietjes (talk) 14:42, 24 November 2017 (UTC)
- it's been several weeks now and the lack of any substantial entries in Category:Pages using sidebar with the child parameter seems to indicate that most templates are using {{subsidebar bodystyle}} instead. assuming nothing changes over the next week or so, we can probably safely change the
|child=yes
feature to replicate the functionality of {{subsidebar bodystyle}} which will solve any potential problems. Frietjes (talk) 22:00, 14 December 2017 (UTC) - now updated. let me know if there are any problems. Frietjes (talk) 17:39, 19 December 2017 (UTC)
- it's been several weeks now and the lack of any substantial entries in Category:Pages using sidebar with the child parameter seems to indicate that most templates are using {{subsidebar bodystyle}} instead. assuming nothing changes over the next week or so, we can probably safely change the
- RolandUnger, (1) I added Category:Pages using sidebar with the child parameter so we can find all the uses and make sure nothing is broken by any changes, (2) many of the subsidebars are using {{subsidebar bodystyle}} to change the outer inline css, (3) a rewrite to use div tags instead of tables was attempted on 3 June 2017, but there were so many problems that it had to be rolled back. basically, you have to have a method for finding/tracking all the places that implicitly assume that sidebar is generating table markup. it's possible to do the conversion and fix all the problems, but you need a method to find/fix all the problems. for example, what was done at Module:Navbox when we added the automatic striping. I agree that having the sitewide css detect that it's a child and style it appropriately would be great, but we would need a method for finding/fixing all the problems. Frietjes (talk) 14:42, 24 November 2017 (UTC)
- Additionally, I like to propose the rewriting of the module. First: all sidebars should have table containers, not only the parent one. Then you can neglect the child parameter. The correct drawing can be made with CSS which can be moved to Common.css. Second: you should replace the tables by div tags. With both ideas you can simplify the code. --RolandUnger (talk) 06:18, 23 November 2017 (UTC)
TemplateStyles in meta templates
Followers of this page may be interested in WT:TemplateStyles#In the context of meta templates. Please take a moment to comment there. --Izno (talk) 01:41, 27 July 2018 (UTC)
Collapsibility
This is a title |
---|
This is above |
Heading 1 |
Content 1 |
Heading 2 |
Content 2 |
This is a title |
---|
This is above |
Heading 1 |
Content 1 |
Heading 2 |
Content 2 |
This is above |
Heading 1 |
---|
Content 1 |
Heading 2 |
Content 2 |
The documentation says that
{{Sidebar with collapsible lists}} is a version of {{Sidebar}} that adds collapsibility to its sections, i.e. the means to show or hide sections by clicking links beside their headings.
Is Template:Sidebar collapsible or noncollapsible, or are only its sections noncollapsible? Hyacinth (talk) 06:55, 29 August 2018 (UTC)
- Hyacinth, it is possible to make an entire {{sidebar}} collapsible by adding the classes to the sidebar. with the
mw-collapsible
class, the show/hide is added to the first available location. I recommend using a combination of font-size and resize to make sure that the show/hide links aren't really big when they are put in the outertitle or title location. Frietjes (talk) 14:57, 29 August 2018 (UTC)
Template:Calculation results
Currently {{Calculation results}} uses table code rather than {{Sidebar}} because the content of each heading uses two columns (one from beginning to the equal sign, and one for what follows the equal sign) and to allow the equal signs to align vertically. The template is tagged: "This template should be converted to a standardized format using Template:Sidebar." Are columns possible in a Sidebar content section / is colspan variable in sidebar content headings? If not, the tag should be removed and a comment should be added to the documentation (and a hidden comment should probably be added at the top). Hyacinth (talk) 01:38, 19 November 2018 (UTC)
- Hyacinth, the typical method for adding columns is to embed an infobox or embed {{aligned table}}. Frietjes (talk) 17:04, 19 November 2018 (UTC)
- Perhaps columns should be mentioned in the documentation for this module. Hyacinth (talk) 04:29, 20 November 2018 (UTC)
Standardisation?
In the archives, some seem to have suggested that sidebar templates ought merely mirror the contents of Template:Navboxes. Thumperward even experimented with a Template:Navbox vertical. While I doubt arguments going that far as to have sidebars exactly mirroring contents of navobxes would be convincing, at least some increased level of standardisation of the looks (rendering) of sidebars could probably be in the interest of the readers of Wikipedia? You could argue that the precurrent variation of looks of sidebars doesn't really serve any real purpose when a WP:CONSENSUS more standardsed looks for sidebars - still suitable for diverse applications over the board - could be achieved? Chicbyaccident (talk) 16:06, 29 November 2018 (UTC)
- Chicbyaccident, {{Military navigation}} uses Module:Navbox to generate sidebars or footer navboxes depending the use of
|style=wide
. Frietjes (talk) 19:58, 29 November 2018 (UTC)
Images
I've noticed that sidebars still use hardcoded images (i.e. [[File:Placeholder.png|20px|caption]]
). Is there a specific reason that a module hasn't been implemented similar to Module:InfoboxImage? Happy to work on that myself, just curious if it is simply a matter of no one having done it yet or if it was a conscious choice to intentionally NOT do that. --Zackmann (Talk to me/What I been doing) 19:01, 30 November 2018 (UTC)
- We don't want to provide users the option to add their own images in sidebars generally in an instantiation of that sidebar in an article, so a module is overkill. --Izno (talk) 19:33, 30 November 2018 (UTC)
- OH duh, this is only called from the template while an infobox is providing the image from the article. DUHHH. Thanks! --Zackmann (Talk to me/What I been doing) 20:14, 30 November 2018 (UTC)
Top margin
Could you please add a top margin (0.5 em) just like Infobox does, so the sidebar and message boxes won't touch (see Politics of Equatorial Guinea)? Thanks. --CaiusSPQR (talk) 00:45, 30 November 2019 (UTC)
Hardcoded element-level background color
This template currently hardcodes a css background color into the style attribute on the table tag with the following line: :css('background', '#f9f9f9')
, which breaks the ability to style it with user CSS (eg Vector), because the style attribute is the most-specific possible identifier and not overrideable. This means you get color clashes when using eg a dark mode theme. There's no need to do this, as you could just use the class="infobox"
to get the same styling as infoboxes have, which is obviously the desire, here. As a darkmode Vector user, I'd appreciate it if someone with the ability to fix this could so. Tossrock (talk) 07:48, 13 December 2019 (UTC)
- Tossrock, I tried this but it broken the alignment. There is more in the infobox class than just the background. However, it does look like the fmbox-system class in MediaWiki:Common.css has just the background. But, it would be really non-intuitive to use that. It would be nice if we had a sidebar class like we have for infobox. Perhaps you can propose this on the talk page for MediaWiki:Common.css? Thanks! Plastikspork ―Œ(talk) 17:49, 26 April 2020 (UTC)
Spacing issue
Hi there, I'm having difficulty fixing a spacing problem. I recently put up Template:Archival records as a sidebar template with an infobox subbox embed. The template works, but it always inserts two line breaks between the top of the template and any text that follows. I haven't been able to put a finger on where the issue comes from. Example of template use here: Ursula Franklin. Scroll to ==External links==
. Utl jung (talk) 19:06, 1 April 2020 (UTC)
- Utl jung, it should be fixed now. Thanks! Plastikspork ―Œ(talk) 17:39, 26 April 2020 (UTC)
- Fantastic. Very much appreciated, thank you Plastikspork! Utl jung (talk) 13:00, 27 April 2020 (UTC)