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 5 | ← | Archive 10 | Archive 11 | Archive 12 | Archive 13 | Archive 14 | Archive 15 |
All boxes on Wikipedia which previous had the ability to collapse are now open (including on talkpages) with the collapse capability disapeared? I tried to follow the trail and led back to here but there hasn't been an edit to this since July. Could somebody find out what has happened and fix it? - Yorkshirian ( talk) 20:44, 22 August 2009 (UTC)
Group headings in Template:Navbox#Child_navboxes should not be bold. It looks too much contrast both because it is in center of template and background is lighter compared to main navbox group name (which is bold but not intrusive). This hides current transcluded article link that is being bolded, so difficult to navigate. So it can be either un-bolded (best) or color can be changed to gray from black. Doorvery far ( talk) 09:45, 25 August 2009 (UTC)
I've followed the above instructions but I am having no luck.
Im getting this displayed, here is a simple snippet:
!--
Please do not edit without discussion first as this is a VERY complex template.
--table class=navbox cellspacing=0 !--
--style=;trtd style=padding:2px;!--
--table cellspacing=0 class=nowraplinks ;;!--
Everything is installed accordingly. So I think.
I have followed http://en.wikipedia.org/wiki/Template_talk:Navbox
along with
http://en.wikipedia.org/wiki/Template_talk:Navbox/Archive_8
But both with no luck. Any help would be great? —Preceding unsigned comment added by Colinliu2009 ( talk • contribs) 11:02, 26 August 2009 (UTC)
With the push towards HTML5...
The attribute cellspacing
is not allowed within table
.
[1] Just a plain {{
navbox}} renders as:
<table class="navbox" cellspacing="0" style=";">
<tr>
<td style="padding:2px;">
<table cellspacing="0" class="nowraplinks" style="width:100%;background:transparent;color:inherit;;"></table>
</td>
</tr>
</table>
Which gives two validation errors. ---— Gadget850 (Ed) talk 17:22, 21 September 2009 (UTC)
Do navboxes go on the very bottom of an article? What about the stub templates? Which goes on top? Just wondering if there is a standard.-- Breandán MacAmhlaidh ( talk) 09:41, 26 September 2009 (UTC)
My personal rule of thumb is that navboxes always go directly above any categories or DEFAULTSORT on a page. I have no idea if there are any actual recommendations, though. 「 ダイノガイ 千?!」 ? · Talk⇒Dinoguy1000 17:04, 26 September 2009 (UTC)
Шаблон:Navbox -- JukoFF ( talk) 07:45, 7 October 2009 (UTC)
I've requested and guided an administrator of the Afrikaans Wikipedia at af.wikipedia.org to add the necessary styles and functions to Common.css and Common.js respectively. Navbox show/hide now works on the Afrikaans Wiki in Safari 3.2.1, Opera 9.6.4, Google Crome 3.0.195.27, and others, EXCEPT on INTERNET EXPLORER (show/hide not visible). You may test my example here: Navbox Example on af.wikipedia.org. Is it possible that the problem might be with /* Scripts specific to Internet Explorer */ being absent from the Afrikaans Common.js, or is it due to another problem? I’ll appreciate anyone’s help to get the IE Navbox show/hide problem solved at af.wikipedia.org. Best regards. --Wordscape 21:00, 22 October 2009 (UTC) —Preceding unsigned comment added by Wordscape ( talk • contribs)
Some testing by User:Dodoïste has opened up interesting aspects of the the navbox system (earlier discussion here and here).
I've dropped a note at Template talk:Navbar#Proposed navbox changes inviting anyone watching that template but not this one to come by and participate - just thought I'd keep everyone on the same page. 「 ダイノガイ 千?!」 ? · Talk⇒Dinoguy1000 17:53, 25 August 2009 (UTC)
Personally I'm particularly concerned about the vde links and their position in the template. I think that the small test by Dodoiste is a clear indication that those should be moved from the top left to either top right, or should be hidden by default, because they are confusing novice editors, and that any usability accessibility improvement should start with this.
I have made a quick demo which shows the inverse of the show/hide and vde links: you can visit
User:TheDJ/Navboxtest with importScript('User:TheDJ/Navboxtest.js')
in your
monobook script, and it will show this simple "inverse" of the two elements navigational elements. —
TheDJ (
talk •
contribs) 15:28, 23 August 2009 (UTC)
List of capital cities of the European Union show
|
List of capital cities of the European Union hide
|
Example of content: Amsterdam · Athens · Berlin · Bratislava · Brussels · Bucharest |
View template · Discuss template · Edit template |
List of capital cities of the European Union hide
|
Example of content: Amsterdam · Athens · Berlin · Bratislava · Brussels · Bucharest |
[edit template] |
In the updated
User:Cacycle/navbox demo it is now possible to always show all three edit links as [view • talk • edit] or [v • d • e] by adding the following CSS code to
User:YourUsername/monobook.css (or
User:YourUsername/vector.css): .navbarEditLinks { display: inline; }
. I have also removed the redundant "this" from the tooltips.
Cacycle (
talk) 03:42, 31 August 2009 (UTC)
The other thing that we can easily tackle and definitely should do, is to add tooltips to the show/hide widget. The question is what should they read ? "Show hidden content", "Show folded content" "Show collapsed content" ? — TheDJ ( talk • contribs) 15:28, 23 August 2009 (UTC)
The problem is see here is that it would affect the centering of the title, unless we add an equal sized span to the left. Seems somewhat convoluted. Anyone any good ideas ? — TheDJ ( talk • contribs) 15:28, 23 August 2009 (UTC)
Safari/Chrome and Opera have this issue, and I believe IE has the same problem, though I cannot check on that. — TheDJ ( talk • contribs) 12:18, 24 August 2009 (UTC)
I would note that moving the show/hide link (as well as the other tweaks suggested to it) are going to require modifying the collapsible tables code in MediaWiki:Common.js. However, there are quite a few other things that use this code, so the different functionality should be provided behind an additional class or something, to ensure that other current usages don't change unexpectedly or break outright when/if these changes get rolled out. 「 ダイノガイ 千?!」 ? · Talk⇒Dinoguy1000 17:31, 24 August 2009 (UTC)
Australian Open men's singles champions show
|
Wimbledon (Open Era) Gentlemen's Singles champions show
|
US Open men's singles champions show
|
Association of Tennis Professionals (ATP) World No. 1 players show
|
Tennis at the Summer Olympics · Olympic Champions in men's doubles show
|
Year-end championships winners show
|
I'm just wondering about moving the show button to the middle. It would mean that they are no longer aligned when there is more than one navbox shown. -- WOSlinker ( talk) 18:02, 25 August 2009 (UTC)
showAustralian Open men's singles champions
|
showWimbledon (Open Era) Gentlemen's Singles champions
|
showUS Open men's singles champions
|
showAssociation of Tennis Professionals (ATP) World No. 1 players
|
showTennis at the Summer Olympics · Olympic Champions in men's doubles
|
showYear-end championships winners
|
Australian Open men's singles champions show
|
Wimbledon (Open Era) Gentlemen's Singles champions show
|
US Open men's singles champions show
|
Association of Tennis Professionals (ATP) World No. 1 players show
|
Tennis at the Summer Olympics · Olympic Champions in men's doubles show
|
Year-end championships winners show
|
When using a wide window on a higher-res screen the show/hide buttons would be out of the context of the text or title. After all, this button is the only clue that there is something hidden and it would be difficult for a newbee to realize that it is actually hidden content related to the title, and not some mysterious unimportant wiki thing. Also, moving the button to the sides would make it difficult to select the correct one out of several and it would need a rather large mouse move action. Therefore, from a usability standpoint the link should be next to the title. Cacycle ( talk) 13:18, 26 August 2009 (UTC)
I have no particular opinion on this. On the one side it's easier for some people to understand, others will say it is redundant. Perhaps a "uncollapse" upon hovering the titlebar is an idea ? I think that will help people a lot quicker. — TheDJ ( talk • contribs) 15:28, 23 August 2009 (UTC)
I did some googling. Properly set up screen readers should read the characters ▼ and ▲ as "black down-pointing triangle" and "black up-pointing triangle", that is their Unicode name. Both characters are part of the WGL4 character set which has bee supported by Windows since Windows 95 as far as I can tell. So they are definitely not "some random Unicode characters". Cacycle ( talk) 12:42, 25 August 2009 (UTC)
The updated User:Cacycle/navbox demo has now full support for images and html constructs. In its default configuration it still uses ▼ and ▲, but these arrows are now invisible to screen readers (it uses :before { content: "▼"; }. Users of screen readers will miss the tooltip ("Click to show hidden content"), but still have the button text ("show"). In my opinion opinion an arrow is essential as the button itself is diguised as normal text and the arrow is the only obvious indicator that there is hidden content. Cacycle ( talk) 03:42, 31 August 2009 (UTC)
This really is a problem, but one that is much more difficult to fix I think. I suppose we best deal with this last. — TheDJ ( talk • contribs) 15:28, 23 August 2009 (UTC)
Yes, specifically the HR elements background. For instance we have default background color #CCCCFF and the links (often the title itself is linked) within it have the blue color #3366BB . According to this calculator, this combination is not WCAG 2 AA compliant in smaller fontsizes and it is NEVER compliant with WCAG 2 AAA. And that is not a good thing. If the title is in black instead of being linked, then everything is fine. — TheDJ ( talk • contribs) 20:17, 23 August 2009 (UTC)
List of capital cities of the European Union show
|
List of capital cities of the European Union show
|
List of capital cities of the European Union show
|
List of capital cities of the European Union show
|
List of capital cities of the European Union show
|
OK, here are the two things we need to do. The color used by Cacycle in his User:Cacycle/navbox.css is a lighter blue (#0645AD) than the usual blue of the links (#002BB8). First of all, we need to use the usual #002BB8. Then, in order to provide enough contrast with the rest of the article, but not too much either, I suggest #ECECFF background (WCAG 2 AAA Compliant, contrast ratio of 9.62) or #0F0F0F (WCAG 2 AAA Compliant, contrast ratio of 9.84). The second one, #0F0F0F, is the color chosen for boxes background by the Usability Initiative, as explained in the Babacco color scheme. Dodoïste ( talk) 09:49, 29 August 2009 (UTC)
Many navboxes include lists, but without them being marked up as lists (often, they're just text, separated with bullets or other such characters). I created {{ Flatlist}} as a first step toward resolving this, but more work - especially on the aesthetics - is needed. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:37, 23 August 2009 (UTC)
I have partially rewritten the JavaScript code behind the collapsible tables a few weeks ago. See http://www.ruudkoot.nl/wiki/MediaWiki:Common.js . It also supports images, which may be preferable over using some random Unicode character as an ad-hoc arrow (might not be available on al browsers.) Is there any interest in this code? I'm very busy until next Friday, by I could finish/make requested changes the following week. Cheers, — Ruud 20:11, 24 August 2009 (UTC)
When 2 or 3 navboxes are stacked there with autocollapse, expanding the first template is best option. All being collapsed doesnt look good. The first template at top of the stack generally most suitable - expanding this would be appropriate. Wikicode already sees if more than 1 template is present and collapses it, so making only first expnaded with others collapsed should not be difficult to implement. Doorvery far ( talk) 09:45, 25 August 2009 (UTC)
A french accessibility expert had a look at this script, and said there is an important mistake to fix. Blind users cannot use the show/hide button with the keyboard. It is important to fix it, because users like
Graham87 would not have access to the content of the navbox with this new script. onclick
should not be used with span
img
or div
element, per
W3C's WCAG 2.0 guideline. W3C explains what to do in
SCR35: Making actions keyboard accessible by using the onclick event of anchors and buttons. Thanks Cacycle. :-)
Dodoïste (
talk) 15:46, 7 November 2009 (UTC)
Although we disagree on several details, there is a clear consensus on the main ideas:
The other things are details that can be fixed later on, so I suggest to push forward. What is the next step ? Should we begin a straw poll, or some kind of vote ? Yours, Dodoïste ( talk) 15:02, 2 September 2009 (UTC)
Okay maybe this is a beginner's question but I typed "listpadding" into search and turned up next to nothing. My question is how does one pad or introduce spacing on the level of the list in a navbox? I think I understand the titlestyle, abovestyle, and belowstyle padding-left:1em; padding-right:1em; switches but I don't get the listpadding switch. Is there an example of how it is properly used? —Preceding unsigned comment added by Lambanog ( talk • contribs) 21:25, 27 October 2009 (UTC)
(←) I don't know of any navbox that actually uses it, but here's a demo (hit edit to see the source):
— Edokter • Talk • 12:56, 28 October 2009 (UTC)
liststyle = padding-left: 20em;
. But that won't guarantee absolute centering, so maybe liststyle = text-align: center; padding-right: 6em;
will do the trick. However, the simplest way to center the list is by not using a group. —
Edokter •
Talk • 15:02, 29 October 2009 (UTC)
Okay so what I thought made sense earlier using liststyle does work at least in some cases. But the help section states:
"Due to complex technical reasons, simply setting "liststyle=padding:0.5em;" (or any other padding setting) will not work."
Hmmm... anyway... thanks again! In case I haven't said it enough.
A closer look and I notice strange things happening with the v d e on my title padded examples. Sigh. — Lambanog ( talk) 16:53, 29 October 2009 (UTC)
{{
editprotected}}
I found out that if I want to use this template with every item in a list on its own line, it renders incorrectly, but not for list1
. E.g.:
{{Navbox |list1= foo bar baz |list2= foo2 bar2 bar2b baz2 }}
This is because there is a linebreak before and after {{{list1}}}
, but those linebreaks aren't around the rest of listn
parameters. For some reason, Mediawiki encloses all lines inside <div>
inside a <p>
except the lines that contain the starting <div>
and the ending </div>
. So, I request that all lines in the form of
--><div style="padding:{{{listpadding|0em 0.25em}}}">{{{listn}}}</div></td></tr>}}<!--
to be changed to
--><div style="padding:{{{listpadding|0em 0.25em}}}"> {{{listn}}} </div></td></tr>}}<!--
where listn
is from list2
to list20
.
Svick (
talk) 16:00, 9 November 2009 (UTC)
I've noticed in the last few days that the height of group1 is more than the other groups when it wasn't before. I noticed there was an edit a few days ago that may have caused this but I don't want to revert it in case it was done for a good reason. Can anyone fix this? Thanks. AnemoneProjectors ( talk) 01:00, 11 November 2009 (UTC)
A bit more info regarding the linebreak in Template:The X Factor:
foo<br>bar bab <br>hey
produces:
<p>foo<br /> bar</p> <p><br /></p> <p>bab<br /> hey</p>
-- MZMcBride ( talk) 03:30, 11 November 2009 (UTC)
{{{listN}}}
:Wikicode in template | Expanded wikicode | HTML | Renders as |
---|---|---|---|
<div>{{{listN}}}</div> |
<div>foo bar baz</div> |
<div>foo <p>bar</p> baz</div> |
foo
bar baz |
<div> {{{listN}}}</div> |
<div> foo bar baz</div> |
<div> <p>foo bar</p> baz</div> |
foo bar baz |
<div> {{{listN}}} </div> |
<div> foo bar baz </div> |
<div> <p>foo bar baz</p> </div> |
foo bar baz |
<br>
is on a new line or not, it renders the same in both cases, no? Or do the linebreaks cause problems in other cases?
Svick (
talk) 17:18, 11 November 2009 (UTC)<br>
on a new line)
does't work and I think it should (and I don't understand how could it not work with MZMcBride's version). Also, I think it is better to format long lists each item on its own line to make editing them little easier. This style is used e.g. in
Template:Airlines of the United States and the list has to be enclosed in <div>
to work properly. For this two things to work, {{{listN}}}
would have to be inserted and you are right that this would enclose all lists in <p>
, but I don't think it would cause any problems.
Svick (
talk) 22:21, 11 November 2009 (UTC)foo <br>bar
<br>s
or newline and <br>
) do that. And the way Template:Airlines of the United States behave when you remove the <div>
s is the same as in my table above in the second row, so it would be fixed by adding the newline. I finally understand now, what was AnemoneProjectors complaining about: the <p>
causes bigger top and bottom margins for all lists, and this is the only problem I think this solution has.
Svick (
talk) 08:21, 12 November 2009 (UTC)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 5 | ← | Archive 10 | Archive 11 | Archive 12 | Archive 13 | Archive 14 | Archive 15 |
All boxes on Wikipedia which previous had the ability to collapse are now open (including on talkpages) with the collapse capability disapeared? I tried to follow the trail and led back to here but there hasn't been an edit to this since July. Could somebody find out what has happened and fix it? - Yorkshirian ( talk) 20:44, 22 August 2009 (UTC)
Group headings in Template:Navbox#Child_navboxes should not be bold. It looks too much contrast both because it is in center of template and background is lighter compared to main navbox group name (which is bold but not intrusive). This hides current transcluded article link that is being bolded, so difficult to navigate. So it can be either un-bolded (best) or color can be changed to gray from black. Doorvery far ( talk) 09:45, 25 August 2009 (UTC)
I've followed the above instructions but I am having no luck.
Im getting this displayed, here is a simple snippet:
!--
Please do not edit without discussion first as this is a VERY complex template.
--table class=navbox cellspacing=0 !--
--style=;trtd style=padding:2px;!--
--table cellspacing=0 class=nowraplinks ;;!--
Everything is installed accordingly. So I think.
I have followed http://en.wikipedia.org/wiki/Template_talk:Navbox
along with
http://en.wikipedia.org/wiki/Template_talk:Navbox/Archive_8
But both with no luck. Any help would be great? —Preceding unsigned comment added by Colinliu2009 ( talk • contribs) 11:02, 26 August 2009 (UTC)
With the push towards HTML5...
The attribute cellspacing
is not allowed within table
.
[1] Just a plain {{
navbox}} renders as:
<table class="navbox" cellspacing="0" style=";">
<tr>
<td style="padding:2px;">
<table cellspacing="0" class="nowraplinks" style="width:100%;background:transparent;color:inherit;;"></table>
</td>
</tr>
</table>
Which gives two validation errors. ---— Gadget850 (Ed) talk 17:22, 21 September 2009 (UTC)
Do navboxes go on the very bottom of an article? What about the stub templates? Which goes on top? Just wondering if there is a standard.-- Breandán MacAmhlaidh ( talk) 09:41, 26 September 2009 (UTC)
My personal rule of thumb is that navboxes always go directly above any categories or DEFAULTSORT on a page. I have no idea if there are any actual recommendations, though. 「 ダイノガイ 千?!」 ? · Talk⇒Dinoguy1000 17:04, 26 September 2009 (UTC)
Шаблон:Navbox -- JukoFF ( talk) 07:45, 7 October 2009 (UTC)
I've requested and guided an administrator of the Afrikaans Wikipedia at af.wikipedia.org to add the necessary styles and functions to Common.css and Common.js respectively. Navbox show/hide now works on the Afrikaans Wiki in Safari 3.2.1, Opera 9.6.4, Google Crome 3.0.195.27, and others, EXCEPT on INTERNET EXPLORER (show/hide not visible). You may test my example here: Navbox Example on af.wikipedia.org. Is it possible that the problem might be with /* Scripts specific to Internet Explorer */ being absent from the Afrikaans Common.js, or is it due to another problem? I’ll appreciate anyone’s help to get the IE Navbox show/hide problem solved at af.wikipedia.org. Best regards. --Wordscape 21:00, 22 October 2009 (UTC) —Preceding unsigned comment added by Wordscape ( talk • contribs)
Some testing by User:Dodoïste has opened up interesting aspects of the the navbox system (earlier discussion here and here).
I've dropped a note at Template talk:Navbar#Proposed navbox changes inviting anyone watching that template but not this one to come by and participate - just thought I'd keep everyone on the same page. 「 ダイノガイ 千?!」 ? · Talk⇒Dinoguy1000 17:53, 25 August 2009 (UTC)
Personally I'm particularly concerned about the vde links and their position in the template. I think that the small test by Dodoiste is a clear indication that those should be moved from the top left to either top right, or should be hidden by default, because they are confusing novice editors, and that any usability accessibility improvement should start with this.
I have made a quick demo which shows the inverse of the show/hide and vde links: you can visit
User:TheDJ/Navboxtest with importScript('User:TheDJ/Navboxtest.js')
in your
monobook script, and it will show this simple "inverse" of the two elements navigational elements. —
TheDJ (
talk •
contribs) 15:28, 23 August 2009 (UTC)
List of capital cities of the European Union show
|
List of capital cities of the European Union hide
|
Example of content: Amsterdam · Athens · Berlin · Bratislava · Brussels · Bucharest |
View template · Discuss template · Edit template |
List of capital cities of the European Union hide
|
Example of content: Amsterdam · Athens · Berlin · Bratislava · Brussels · Bucharest |
[edit template] |
In the updated
User:Cacycle/navbox demo it is now possible to always show all three edit links as [view • talk • edit] or [v • d • e] by adding the following CSS code to
User:YourUsername/monobook.css (or
User:YourUsername/vector.css): .navbarEditLinks { display: inline; }
. I have also removed the redundant "this" from the tooltips.
Cacycle (
talk) 03:42, 31 August 2009 (UTC)
The other thing that we can easily tackle and definitely should do, is to add tooltips to the show/hide widget. The question is what should they read ? "Show hidden content", "Show folded content" "Show collapsed content" ? — TheDJ ( talk • contribs) 15:28, 23 August 2009 (UTC)
The problem is see here is that it would affect the centering of the title, unless we add an equal sized span to the left. Seems somewhat convoluted. Anyone any good ideas ? — TheDJ ( talk • contribs) 15:28, 23 August 2009 (UTC)
Safari/Chrome and Opera have this issue, and I believe IE has the same problem, though I cannot check on that. — TheDJ ( talk • contribs) 12:18, 24 August 2009 (UTC)
I would note that moving the show/hide link (as well as the other tweaks suggested to it) are going to require modifying the collapsible tables code in MediaWiki:Common.js. However, there are quite a few other things that use this code, so the different functionality should be provided behind an additional class or something, to ensure that other current usages don't change unexpectedly or break outright when/if these changes get rolled out. 「 ダイノガイ 千?!」 ? · Talk⇒Dinoguy1000 17:31, 24 August 2009 (UTC)
Australian Open men's singles champions show
|
Wimbledon (Open Era) Gentlemen's Singles champions show
|
US Open men's singles champions show
|
Association of Tennis Professionals (ATP) World No. 1 players show
|
Tennis at the Summer Olympics · Olympic Champions in men's doubles show
|
Year-end championships winners show
|
I'm just wondering about moving the show button to the middle. It would mean that they are no longer aligned when there is more than one navbox shown. -- WOSlinker ( talk) 18:02, 25 August 2009 (UTC)
showAustralian Open men's singles champions
|
showWimbledon (Open Era) Gentlemen's Singles champions
|
showUS Open men's singles champions
|
showAssociation of Tennis Professionals (ATP) World No. 1 players
|
showTennis at the Summer Olympics · Olympic Champions in men's doubles
|
showYear-end championships winners
|
Australian Open men's singles champions show
|
Wimbledon (Open Era) Gentlemen's Singles champions show
|
US Open men's singles champions show
|
Association of Tennis Professionals (ATP) World No. 1 players show
|
Tennis at the Summer Olympics · Olympic Champions in men's doubles show
|
Year-end championships winners show
|
When using a wide window on a higher-res screen the show/hide buttons would be out of the context of the text or title. After all, this button is the only clue that there is something hidden and it would be difficult for a newbee to realize that it is actually hidden content related to the title, and not some mysterious unimportant wiki thing. Also, moving the button to the sides would make it difficult to select the correct one out of several and it would need a rather large mouse move action. Therefore, from a usability standpoint the link should be next to the title. Cacycle ( talk) 13:18, 26 August 2009 (UTC)
I have no particular opinion on this. On the one side it's easier for some people to understand, others will say it is redundant. Perhaps a "uncollapse" upon hovering the titlebar is an idea ? I think that will help people a lot quicker. — TheDJ ( talk • contribs) 15:28, 23 August 2009 (UTC)
I did some googling. Properly set up screen readers should read the characters ▼ and ▲ as "black down-pointing triangle" and "black up-pointing triangle", that is their Unicode name. Both characters are part of the WGL4 character set which has bee supported by Windows since Windows 95 as far as I can tell. So they are definitely not "some random Unicode characters". Cacycle ( talk) 12:42, 25 August 2009 (UTC)
The updated User:Cacycle/navbox demo has now full support for images and html constructs. In its default configuration it still uses ▼ and ▲, but these arrows are now invisible to screen readers (it uses :before { content: "▼"; }. Users of screen readers will miss the tooltip ("Click to show hidden content"), but still have the button text ("show"). In my opinion opinion an arrow is essential as the button itself is diguised as normal text and the arrow is the only obvious indicator that there is hidden content. Cacycle ( talk) 03:42, 31 August 2009 (UTC)
This really is a problem, but one that is much more difficult to fix I think. I suppose we best deal with this last. — TheDJ ( talk • contribs) 15:28, 23 August 2009 (UTC)
Yes, specifically the HR elements background. For instance we have default background color #CCCCFF and the links (often the title itself is linked) within it have the blue color #3366BB . According to this calculator, this combination is not WCAG 2 AA compliant in smaller fontsizes and it is NEVER compliant with WCAG 2 AAA. And that is not a good thing. If the title is in black instead of being linked, then everything is fine. — TheDJ ( talk • contribs) 20:17, 23 August 2009 (UTC)
List of capital cities of the European Union show
|
List of capital cities of the European Union show
|
List of capital cities of the European Union show
|
List of capital cities of the European Union show
|
List of capital cities of the European Union show
|
OK, here are the two things we need to do. The color used by Cacycle in his User:Cacycle/navbox.css is a lighter blue (#0645AD) than the usual blue of the links (#002BB8). First of all, we need to use the usual #002BB8. Then, in order to provide enough contrast with the rest of the article, but not too much either, I suggest #ECECFF background (WCAG 2 AAA Compliant, contrast ratio of 9.62) or #0F0F0F (WCAG 2 AAA Compliant, contrast ratio of 9.84). The second one, #0F0F0F, is the color chosen for boxes background by the Usability Initiative, as explained in the Babacco color scheme. Dodoïste ( talk) 09:49, 29 August 2009 (UTC)
Many navboxes include lists, but without them being marked up as lists (often, they're just text, separated with bullets or other such characters). I created {{ Flatlist}} as a first step toward resolving this, but more work - especially on the aesthetics - is needed. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:37, 23 August 2009 (UTC)
I have partially rewritten the JavaScript code behind the collapsible tables a few weeks ago. See http://www.ruudkoot.nl/wiki/MediaWiki:Common.js . It also supports images, which may be preferable over using some random Unicode character as an ad-hoc arrow (might not be available on al browsers.) Is there any interest in this code? I'm very busy until next Friday, by I could finish/make requested changes the following week. Cheers, — Ruud 20:11, 24 August 2009 (UTC)
When 2 or 3 navboxes are stacked there with autocollapse, expanding the first template is best option. All being collapsed doesnt look good. The first template at top of the stack generally most suitable - expanding this would be appropriate. Wikicode already sees if more than 1 template is present and collapses it, so making only first expnaded with others collapsed should not be difficult to implement. Doorvery far ( talk) 09:45, 25 August 2009 (UTC)
A french accessibility expert had a look at this script, and said there is an important mistake to fix. Blind users cannot use the show/hide button with the keyboard. It is important to fix it, because users like
Graham87 would not have access to the content of the navbox with this new script. onclick
should not be used with span
img
or div
element, per
W3C's WCAG 2.0 guideline. W3C explains what to do in
SCR35: Making actions keyboard accessible by using the onclick event of anchors and buttons. Thanks Cacycle. :-)
Dodoïste (
talk) 15:46, 7 November 2009 (UTC)
Although we disagree on several details, there is a clear consensus on the main ideas:
The other things are details that can be fixed later on, so I suggest to push forward. What is the next step ? Should we begin a straw poll, or some kind of vote ? Yours, Dodoïste ( talk) 15:02, 2 September 2009 (UTC)
Okay maybe this is a beginner's question but I typed "listpadding" into search and turned up next to nothing. My question is how does one pad or introduce spacing on the level of the list in a navbox? I think I understand the titlestyle, abovestyle, and belowstyle padding-left:1em; padding-right:1em; switches but I don't get the listpadding switch. Is there an example of how it is properly used? —Preceding unsigned comment added by Lambanog ( talk • contribs) 21:25, 27 October 2009 (UTC)
(←) I don't know of any navbox that actually uses it, but here's a demo (hit edit to see the source):
— Edokter • Talk • 12:56, 28 October 2009 (UTC)
liststyle = padding-left: 20em;
. But that won't guarantee absolute centering, so maybe liststyle = text-align: center; padding-right: 6em;
will do the trick. However, the simplest way to center the list is by not using a group. —
Edokter •
Talk • 15:02, 29 October 2009 (UTC)
Okay so what I thought made sense earlier using liststyle does work at least in some cases. But the help section states:
"Due to complex technical reasons, simply setting "liststyle=padding:0.5em;" (or any other padding setting) will not work."
Hmmm... anyway... thanks again! In case I haven't said it enough.
A closer look and I notice strange things happening with the v d e on my title padded examples. Sigh. — Lambanog ( talk) 16:53, 29 October 2009 (UTC)
{{
editprotected}}
I found out that if I want to use this template with every item in a list on its own line, it renders incorrectly, but not for list1
. E.g.:
{{Navbox |list1= foo bar baz |list2= foo2 bar2 bar2b baz2 }}
This is because there is a linebreak before and after {{{list1}}}
, but those linebreaks aren't around the rest of listn
parameters. For some reason, Mediawiki encloses all lines inside <div>
inside a <p>
except the lines that contain the starting <div>
and the ending </div>
. So, I request that all lines in the form of
--><div style="padding:{{{listpadding|0em 0.25em}}}">{{{listn}}}</div></td></tr>}}<!--
to be changed to
--><div style="padding:{{{listpadding|0em 0.25em}}}"> {{{listn}}} </div></td></tr>}}<!--
where listn
is from list2
to list20
.
Svick (
talk) 16:00, 9 November 2009 (UTC)
I've noticed in the last few days that the height of group1 is more than the other groups when it wasn't before. I noticed there was an edit a few days ago that may have caused this but I don't want to revert it in case it was done for a good reason. Can anyone fix this? Thanks. AnemoneProjectors ( talk) 01:00, 11 November 2009 (UTC)
A bit more info regarding the linebreak in Template:The X Factor:
foo<br>bar bab <br>hey
produces:
<p>foo<br /> bar</p> <p><br /></p> <p>bab<br /> hey</p>
-- MZMcBride ( talk) 03:30, 11 November 2009 (UTC)
{{{listN}}}
:Wikicode in template | Expanded wikicode | HTML | Renders as |
---|---|---|---|
<div>{{{listN}}}</div> |
<div>foo bar baz</div> |
<div>foo <p>bar</p> baz</div> |
foo
bar baz |
<div> {{{listN}}}</div> |
<div> foo bar baz</div> |
<div> <p>foo bar</p> baz</div> |
foo bar baz |
<div> {{{listN}}} </div> |
<div> foo bar baz </div> |
<div> <p>foo bar baz</p> </div> |
foo bar baz |
<br>
is on a new line or not, it renders the same in both cases, no? Or do the linebreaks cause problems in other cases?
Svick (
talk) 17:18, 11 November 2009 (UTC)<br>
on a new line)
does't work and I think it should (and I don't understand how could it not work with MZMcBride's version). Also, I think it is better to format long lists each item on its own line to make editing them little easier. This style is used e.g. in
Template:Airlines of the United States and the list has to be enclosed in <div>
to work properly. For this two things to work, {{{listN}}}
would have to be inserted and you are right that this would enclose all lists in <p>
, but I don't think it would cause any problems.
Svick (
talk) 22:21, 11 November 2009 (UTC)foo <br>bar
<br>s
or newline and <br>
) do that. And the way Template:Airlines of the United States behave when you remove the <div>
s is the same as in my table above in the second row, so it would be fixed by adding the newline. I finally understand now, what was AnemoneProjectors complaining about: the <p>
causes bigger top and bottom margins for all lists, and this is the only problem I think this solution has.
Svick (
talk) 08:21, 12 November 2009 (UTC)