![]() | This page 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. |
![]() | This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
I'm reissuing the request from 21 February – to reduce the template's default width from 22.0em to 20.0em for the sake of smaller screens/windows – as I don't believe its first outing was given, so to speak, enough light of day. Screen resolutions of 1024 by 768 or less may be ever more uncommon nowadays, although I know older people who (e.g.) browse using 1024 by 768 on a widescreen as they find it easier on their eyes. Furthermore, though, this template's present default width also seems to assume Wikipedia will be viewed full-screen, which I know is not always the case. I'm therefore suggesting 20.0em as a compromise between the present 22.0em and the 18.0em specified by quite a few Sidebars I've seen (see above).
The change may be made by replacing the line
-->width:{{#if:{{{width|}}} |{{{width}}} |22.0em}};<!--
near the top of the code with
-->width:{{#if:{{{width|}}} |{{{width}}} |20.0em<!--this default/fallback width no greater than 20.0em, please, for the sake of smaller screens/windows-->}};<!--
CsDix ( talk) 05:17, 24 February 2013 (UTC)
![]() | This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
Please replace the current "below" line (near the end of the code) ...
-->{{#if: {{{below|}}} |<tr><td class="{{{belowclass|}}}" style="padding:0.3em 0.4em 0.3em;font-weight:bold;{{{belowstyle|}}}"> {{{below}}}</td> </tr> }}<!--
...with the following version, where the top padding has been halved to 0.15em...
-->{{#if:{{{below|}}} |<tr><td class="{{{belowclass|}}}" style="padding:0.15em 0.4em 0.3em;font-weight:bold;{{{belowstyle|}}}"> {{{below}}}</td> </tr> }}<!--
...because when border lines above and below the "below" line have been specified, I keep finding the need to set this padding in order to position the line halfway between them (i.e. in a balanced fashion).
CsDix ( talk) 05:11, 27 February 2013 (UTC)
Hello again. Is it possible to set a default width that's more sophisticated than simply "width:Xunits"? What I have in mind is "width:18.0em" combined with "width:auto" – in other words, "18.0em but a bit more if Wikipedia's automatic link-bolding means that 18.0em is exceeded slightly".
18.0em is less than the current "non-bolding-sensitive" 22.0em, as 22.0em is a bit wide on smaller screens (e.g. 1024 by 768 resolution) or in smaller windows, so that reduction would also form part of my edit request. (Why 18.0em? It seems to work satisfactorily in said resolution and I've seen it's also used as the default width for sets of Sidebars, e.g. on political topics.)
CsDix ( talk) 18:13, 16 February 2013 (UTC)
min-width
and max-width
CSS, which is not yet supported by all major browsers (yours might support it for
your own CSS). Whether we care if there is support may be a different question. Otherwise, I support what Frietjes has said. --
Izno (
talk)
17:46, 19 February 2013 (UTC)Informative discussion above IMO. Let me ask some questions first, which anyone(s) can answer.
Q1T. Does browser dependence of "hanging dots" mean that a blank line before • Link F • Link G may, depending on the browser, move the • before Link F to the previous text line?
Q2T. Do "unmanaged hlists" refer to those that have that have not used blank lines to avert end-of-line hanging dots? If yes, are hanging dots in that case also browser dependent?
If there any other points my questions may be missing, feel free to elaborate. P.S. 2 sidebars here IMO opinion show the advantage of the above proposal (in template A). Thank you. -- Thomasmeeks ( talk) 19:37, 21 March 2013 (UTC)
Well, if a blank coding line would present an accessibility problem, one possible solution (as in the Template:Politics sidebar)) would be to replace the coded blank line with a coded line of:
:
instead. That's not a blank line as coded at the WP:LISTGAP guideline. Comments welcome. -- Thomasmeeks ( talk) 13:06, 22 March 2013 (UTC)
Q3T. OK, so does a "low-level" fix for hanging end-line dots mean such list vs. hlist formatting as you introduced here (ingeniously IMO)? -- Thomasmeeks ( talk) 16:35, 23 March 2013 (UTC)
Q4T. As an illustration, wouldn't using your hlist formatting (per Q3T here example):
which (with other sidebar formatting) would look like this:
throughout a contents section of the sidebar allow for customized text-line length without use of list statements and without end-of-line dots? -- Thomasmeeks ( talk) 12:06, 24 March 2013 (UTC)
<ul> <li>item 1</li> <li>item 2</li> <li>item 3</li> <li>item 4</li> </ul>
<ul> <li>item 1</li> <li>item 2</li> </ul> <ul> <li>item 3</li> <li>item 4</li> </ul>
or
<ul> <li><ul> <li>item 1</li> <li>item 2</li> </ul></li> <li><ul> <li>item 3</li> <li>item 4</li> </ul></li> </ul>
1T. The advice at
WP:LISTGAP of no blank line between successive links seems entirely appropriate for bulleted vertical lists, because a blank line is seen only in
WP:Markup but read as "end-of-list" by
screen readers (per Frietjes comment above), hence either unseen or worse. So, Advantage: No blank lines for bulleted vertical lists.
2T. The advantage as to WP:Accessibility arguably shifts toward favoring use of a blank lines when they preserve a useful h[orizontal]list relationship among links on a given line or between successive lines. That is consistent with WP:SIDEBAR, paragraphs 4-6 from bottom as to reflecting that links are related to each other, in this case by placement of a given set of links on a given sidebar line. That also makes each line a horizontal list, like a line in a poem, & meant to be read not only as to individual links but in relation to each other. Successive lines then are similar to successive lines in a poem.
The screenreader appropriately picks up on that at each such line (read as "end of list"). That explains why use of a blank line suppresses a end-of-line dots. The remaining dots on that line are meant only to separate links there. End-of-line dots are redundant for that purpose. The fact that all links are in a content section arguably also makes end-of-line dots redundant. It's already apparent that all links in a given content section should be related to each other without the need for end-of-line dots. (Of course end-of-line dots could be retained with the list default but at the cost of end-of-line dots, which also may widen slightly text lines.)
3T. A link that shows the differences from using (or not) blank lines between links to generate successive sidebar lines is a reworking of the Template:Economics sidebar here. In it, template (A) uses blank lines between some links to generate lines closer to the Journal Economic Literature JEL classification codes, For example:
(B) there uses no blank lines between links, which results in listing that moves up by a line & by default (unintentionally) the first link on all lines from Public & Welfare econ & after. This breaks the narrative of (B), compared to the JEL-code-friendly (A). For example the last line of the previous paragraph in (B) becomes:
which is not a JEL code. That's comparable to moving up the first word in successive lines in a poem to the previous line (not good). -- Thomasmeeks ( talk) 20:54, 8 April 2013 (UTC)
4T. The proposal at the top is for a 18em sidebar vs. the 22em default (about 20% wider). That complements the 2 preceding points. Given the difficulty of finding complementary links per line and resulting narrower text-line lengths, the narrower sidebar width wastes less horizontal line space and thereby makes the sidebar less obtrusive. -- Thomasmeeks ( talk) 19:24, 2 May 2013 (UTC)
![]() | This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
I mocked up a version that supports |child=yes
, in the same way that {{infobox}}
supports |child=yes
. the code is in sandbox2 (it looked like the main sandbox was in use). an example is presented in
Template:Sidebar/testcases#Embedding. I made it not render the navbar, and ignore any outertitle, pretitle, or preimage in the child. I could make it still support pretitle and preimage, but outertitle won't work since it's part of the table caption. the reason for ignoring the others was to make |title=
work in the child in the same way that it work in {{infobox}}
(i.e., have it not output the leading <tr> and <td> for that row to avoid blank rows). if there are no problems with the code, I will make an edit request, and see about merging it with the lua module as well.
Frietjes (
talk)
20:12, 24 May 2013 (UTC)
Many Sidebars are in Category:Exclude in print so they are not rendered in the Books created from Extension:Collection. Unfortunately the underlying functionality is currently broken. As noted in a related bug report there is a workaround,
Content that is not supposed to be included in the PDF can already be marked with the css class "noprint": > <div class="noprint">blub noprint</div>
As an example Template:Navbar is constructed with <div class="noprint"> so navigation bars are not included in Books. Would it be feasible to change the template to include this change rather than requiring each sidebar using the template to be changed? -- Peculiar Investor ( talk) 13:56, 1 November 2013 (UTC)
I was going to play around with creating a Lua version of this template, but then I noticed that Toohool created one about a year ago ( Template:Sidebar/sandbox). Would anyone object if I finish it up and switch us over to it? Kaldari ( talk) 22:52, 30 January 2014 (UTC)
Are parameters such as |heading1class=
|heading2class=
etc meant to work here?
Sardanaphalus (
talk)
09:41, 9 June 2014 (UTC)
|heading1style=
etc.) There is only |headingclass=
. See
Template:Sidebar#Full blank syntax for all supported parameters. —
Edokter (
talk) —
09:49, 9 June 2014 (UTC)
![]() | This page 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. |
![]() | This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
I'm reissuing the request from 21 February – to reduce the template's default width from 22.0em to 20.0em for the sake of smaller screens/windows – as I don't believe its first outing was given, so to speak, enough light of day. Screen resolutions of 1024 by 768 or less may be ever more uncommon nowadays, although I know older people who (e.g.) browse using 1024 by 768 on a widescreen as they find it easier on their eyes. Furthermore, though, this template's present default width also seems to assume Wikipedia will be viewed full-screen, which I know is not always the case. I'm therefore suggesting 20.0em as a compromise between the present 22.0em and the 18.0em specified by quite a few Sidebars I've seen (see above).
The change may be made by replacing the line
-->width:{{#if:{{{width|}}} |{{{width}}} |22.0em}};<!--
near the top of the code with
-->width:{{#if:{{{width|}}} |{{{width}}} |20.0em<!--this default/fallback width no greater than 20.0em, please, for the sake of smaller screens/windows-->}};<!--
CsDix ( talk) 05:17, 24 February 2013 (UTC)
![]() | This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
Please replace the current "below" line (near the end of the code) ...
-->{{#if: {{{below|}}} |<tr><td class="{{{belowclass|}}}" style="padding:0.3em 0.4em 0.3em;font-weight:bold;{{{belowstyle|}}}"> {{{below}}}</td> </tr> }}<!--
...with the following version, where the top padding has been halved to 0.15em...
-->{{#if:{{{below|}}} |<tr><td class="{{{belowclass|}}}" style="padding:0.15em 0.4em 0.3em;font-weight:bold;{{{belowstyle|}}}"> {{{below}}}</td> </tr> }}<!--
...because when border lines above and below the "below" line have been specified, I keep finding the need to set this padding in order to position the line halfway between them (i.e. in a balanced fashion).
CsDix ( talk) 05:11, 27 February 2013 (UTC)
Hello again. Is it possible to set a default width that's more sophisticated than simply "width:Xunits"? What I have in mind is "width:18.0em" combined with "width:auto" – in other words, "18.0em but a bit more if Wikipedia's automatic link-bolding means that 18.0em is exceeded slightly".
18.0em is less than the current "non-bolding-sensitive" 22.0em, as 22.0em is a bit wide on smaller screens (e.g. 1024 by 768 resolution) or in smaller windows, so that reduction would also form part of my edit request. (Why 18.0em? It seems to work satisfactorily in said resolution and I've seen it's also used as the default width for sets of Sidebars, e.g. on political topics.)
CsDix ( talk) 18:13, 16 February 2013 (UTC)
min-width
and max-width
CSS, which is not yet supported by all major browsers (yours might support it for
your own CSS). Whether we care if there is support may be a different question. Otherwise, I support what Frietjes has said. --
Izno (
talk)
17:46, 19 February 2013 (UTC)Informative discussion above IMO. Let me ask some questions first, which anyone(s) can answer.
Q1T. Does browser dependence of "hanging dots" mean that a blank line before • Link F • Link G may, depending on the browser, move the • before Link F to the previous text line?
Q2T. Do "unmanaged hlists" refer to those that have that have not used blank lines to avert end-of-line hanging dots? If yes, are hanging dots in that case also browser dependent?
If there any other points my questions may be missing, feel free to elaborate. P.S. 2 sidebars here IMO opinion show the advantage of the above proposal (in template A). Thank you. -- Thomasmeeks ( talk) 19:37, 21 March 2013 (UTC)
Well, if a blank coding line would present an accessibility problem, one possible solution (as in the Template:Politics sidebar)) would be to replace the coded blank line with a coded line of:
:
instead. That's not a blank line as coded at the WP:LISTGAP guideline. Comments welcome. -- Thomasmeeks ( talk) 13:06, 22 March 2013 (UTC)
Q3T. OK, so does a "low-level" fix for hanging end-line dots mean such list vs. hlist formatting as you introduced here (ingeniously IMO)? -- Thomasmeeks ( talk) 16:35, 23 March 2013 (UTC)
Q4T. As an illustration, wouldn't using your hlist formatting (per Q3T here example):
which (with other sidebar formatting) would look like this:
throughout a contents section of the sidebar allow for customized text-line length without use of list statements and without end-of-line dots? -- Thomasmeeks ( talk) 12:06, 24 March 2013 (UTC)
<ul> <li>item 1</li> <li>item 2</li> <li>item 3</li> <li>item 4</li> </ul>
<ul> <li>item 1</li> <li>item 2</li> </ul> <ul> <li>item 3</li> <li>item 4</li> </ul>
or
<ul> <li><ul> <li>item 1</li> <li>item 2</li> </ul></li> <li><ul> <li>item 3</li> <li>item 4</li> </ul></li> </ul>
1T. The advice at
WP:LISTGAP of no blank line between successive links seems entirely appropriate for bulleted vertical lists, because a blank line is seen only in
WP:Markup but read as "end-of-list" by
screen readers (per Frietjes comment above), hence either unseen or worse. So, Advantage: No blank lines for bulleted vertical lists.
2T. The advantage as to WP:Accessibility arguably shifts toward favoring use of a blank lines when they preserve a useful h[orizontal]list relationship among links on a given line or between successive lines. That is consistent with WP:SIDEBAR, paragraphs 4-6 from bottom as to reflecting that links are related to each other, in this case by placement of a given set of links on a given sidebar line. That also makes each line a horizontal list, like a line in a poem, & meant to be read not only as to individual links but in relation to each other. Successive lines then are similar to successive lines in a poem.
The screenreader appropriately picks up on that at each such line (read as "end of list"). That explains why use of a blank line suppresses a end-of-line dots. The remaining dots on that line are meant only to separate links there. End-of-line dots are redundant for that purpose. The fact that all links are in a content section arguably also makes end-of-line dots redundant. It's already apparent that all links in a given content section should be related to each other without the need for end-of-line dots. (Of course end-of-line dots could be retained with the list default but at the cost of end-of-line dots, which also may widen slightly text lines.)
3T. A link that shows the differences from using (or not) blank lines between links to generate successive sidebar lines is a reworking of the Template:Economics sidebar here. In it, template (A) uses blank lines between some links to generate lines closer to the Journal Economic Literature JEL classification codes, For example:
(B) there uses no blank lines between links, which results in listing that moves up by a line & by default (unintentionally) the first link on all lines from Public & Welfare econ & after. This breaks the narrative of (B), compared to the JEL-code-friendly (A). For example the last line of the previous paragraph in (B) becomes:
which is not a JEL code. That's comparable to moving up the first word in successive lines in a poem to the previous line (not good). -- Thomasmeeks ( talk) 20:54, 8 April 2013 (UTC)
4T. The proposal at the top is for a 18em sidebar vs. the 22em default (about 20% wider). That complements the 2 preceding points. Given the difficulty of finding complementary links per line and resulting narrower text-line lengths, the narrower sidebar width wastes less horizontal line space and thereby makes the sidebar less obtrusive. -- Thomasmeeks ( talk) 19:24, 2 May 2013 (UTC)
![]() | This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
I mocked up a version that supports |child=yes
, in the same way that {{infobox}}
supports |child=yes
. the code is in sandbox2 (it looked like the main sandbox was in use). an example is presented in
Template:Sidebar/testcases#Embedding. I made it not render the navbar, and ignore any outertitle, pretitle, or preimage in the child. I could make it still support pretitle and preimage, but outertitle won't work since it's part of the table caption. the reason for ignoring the others was to make |title=
work in the child in the same way that it work in {{infobox}}
(i.e., have it not output the leading <tr> and <td> for that row to avoid blank rows). if there are no problems with the code, I will make an edit request, and see about merging it with the lua module as well.
Frietjes (
talk)
20:12, 24 May 2013 (UTC)
Many Sidebars are in Category:Exclude in print so they are not rendered in the Books created from Extension:Collection. Unfortunately the underlying functionality is currently broken. As noted in a related bug report there is a workaround,
Content that is not supposed to be included in the PDF can already be marked with the css class "noprint": > <div class="noprint">blub noprint</div>
As an example Template:Navbar is constructed with <div class="noprint"> so navigation bars are not included in Books. Would it be feasible to change the template to include this change rather than requiring each sidebar using the template to be changed? -- Peculiar Investor ( talk) 13:56, 1 November 2013 (UTC)
I was going to play around with creating a Lua version of this template, but then I noticed that Toohool created one about a year ago ( Template:Sidebar/sandbox). Would anyone object if I finish it up and switch us over to it? Kaldari ( talk) 22:52, 30 January 2014 (UTC)
Are parameters such as |heading1class=
|heading2class=
etc meant to work here?
Sardanaphalus (
talk)
09:41, 9 June 2014 (UTC)
|heading1style=
etc.) There is only |headingclass=
. See
Template:Sidebar#Full blank syntax for all supported parameters. —
Edokter (
talk) —
09:49, 9 June 2014 (UTC)