Template talk:Navbox
![]() | Please read before posting These are responses for some frequently asked questions. If they don't help, please feel free to post with your question anyways.
|
|
This page has archives. Sections older than 180 days may be automatically archived by Lowercase sigmabot III when more than 4 sections are present. |
Why is HTML tidy required?
I ask because HTML tidy conflicts with FCK editor, which we use. So we have to switch it off, which implies you cannot use FCK editor & navboxes together! But when I switch off HTML tidy the navboxes look OK. --Robinson weijman (talk) 13:56, 21 January 2011 (UTC)
- Perhaps this was true for an older version of MediaWiki? If navboxes do indeed work with Tidy disabled, we should revise the documentation. (But I cannot test it for myself.) — Edokter • Talk — 21:10, 21 January 2011 (UTC)
- I can confirm that HTML tidy is not needed, at least, on version 1.16. The "fixed" version provided on the wikify project refuses to render right, copying the template wholesale from Template:Navbox works properly. And HTML tidy is NOT installed on my server. TheGreatTK (talk) 18:59, 21 June 2011 (UTC)
Transwiki Navbox
Hey,
I am trying to transwiki the Navbox to my wiki. I have copied over the Common.css and the Common.js as well as the Transwiki versions of TL:Navbox and TL:Navbar. I have also installed parser functions. However, as you can see here, the collapse link won't show up. Any suggestions?--213.196.218.100 (talk) 18:23, 12 April 2011 (UTC)
- I'm having the same exact problem. I've tried it with and without HTML Tidy and I get the same result: no show/hide button. Can anyone help? Cgseif323 (talk) 19:58, 15 July 2011 (UTC)
- I had to go here and make sure my code matched. If it still doesn't work, check the talk page. --Wikisian (talk) 13:32, 1 August 2011 (UTC)
Semantic and accesssible list markup
Many thousands of Wikipedia articles have navboxes, in which lists of links are presented, horizontally, without using list mark-up, but instead using {{·}}
or suchlike as a kludge. This is semantically poor and has implications for accessibility; not least as every {{·}}
is read out as the word "bullet", to blind people using screen-readers.
To remedy that, a group of editors have collaborated to add to Common.css a class called hlist
to which is now used by {{Flatlist}}. Here's a sample edit, adding it to a navbox. The visual output should be the same in all modern browsers; this has been widely tested.
The question now, is how best to apply the class to navboxes across Wikipedia? A bot job, obviously, but using {{flatlist}}
, or some other mechanism? And are there any issues we should be aware of first? {{flatlist}}
can be used with ordinary (UL
) or ordered (OL
) lists. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 18:37, 22 April 2011 (UTC)
- On IE8 (at least), this does not look good. The bullet is immediately adjacent to the right-most word instead of centered between list elements. I would not want to see this deployed without aesthetic improvements first. — Andrwsc (talk · contribs) 18:53, 22 April 2011 (UTC)
- Odd. Looks good on my IE8, with the exception of a bullet added after te last item. — Edokter (talk) — 19:01, 22 April 2011 (UTC)
- Specific CSS issues are best discussed at MediaWiki Talk:Common.css#Horizontal lists. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 19:05, 22 April 2011 (UTC)
- …which you are doing, of course. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 19:24, 22 April 2011 (UTC)
- You may need to do a hard refresh/ clear your cache. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 19:05, 22 April 2011 (UTC)
- Tried that, no effect. I have no custom css etc., just the vanilla wikipedia browsing experience. I see the same effects when I log off. — Andrwsc (talk · contribs) 19:07, 22 April 2011 (UTC)
- Get a proper browser ;-) Seriously, I've just tried IE8, and don't see that spacing problem. Can you try zooming in and out, please, and see if that makes a difference. Again, MediaWiki Talk:Common.css#Horizontal lists is the best place to continue this. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 19:24, 22 April 2011 (UTC)
- Tried that, no effect. I have no custom css etc., just the vanilla wikipedia browsing experience. I see the same effects when I log off. — Andrwsc (talk · contribs) 19:07, 22 April 2011 (UTC)
- Odd. Looks good on my IE8, with the exception of a bullet added after te last item. — Edokter (talk) — 19:01, 22 April 2011 (UTC)
See also two related deletion debates. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 19:10, 22 April 2011 (UTC)
Just wondering if it would be worth adding a |flatlist=yes
parameter to the navbox template to allow for an option of making all the lists use the hlist class. -- WOSlinker (talk) 20:22, 22 April 2011 (UTC)
For example:
{{Navbox/sandbox |navbar=plain |title = Example |group1=Group 1 |list1= *Item 1 *Item 2 *Item 3 *Item 4 *Item 5 *Item 6 *Item 7 *Item 8 |group2=Group 2 |list2= *Item 1 *Item 2 *Item 3 *Item 4 *Item 5 *Item 6 *Item 7 *Item 8 }}
- It may not need the parameter... How many navboxes do you see that have (vertical) bulleted lists? Just assign the "hlist
nomargin" classes to the list cells. — Edokter (talk) — 20:27, 22 April 2011 (UTC)- Template:Navbox with columns comes to mind as a place where vertical lists might be (more properly) used.
On another note, I support this general change. --Izno (talk) 21:24, 22 April 2011 (UTC)- Hadn't thought of that. Shouldn't be hard to filter out. — Edokter (talk) — 22:59, 22 April 2011 (UTC)
- Template:Navbox with columns comes to mind as a place where vertical lists might be (more properly) used.
How can we move this forward? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:56, 27 April 2011 (UTC)
- We'll get to it. Currently investigating {{navbox with columns}} for use of bulleted lists. — Edokter (talk) — 00:52, 29 April 2011 (UTC)
Any news? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 14:13, 17 May 2011 (UTC)
- Nudge. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 23:30, 24 August 2011 (UTC)
- I would just like to say, I would rather see this named
|vlist=yes
and just have {{Navbox}} and friends directly implement what {{flatlist}} does without the extra template inclusion by using hlist CSS class by default on lists within|listn=
(there is already a<div>...</div>
on each one). Anything that uses{{·}}
will not have any issues with this default and allows them to (in most cases) be converted in a straightforward manner. 67.210.196.5 (talk) 17:27, 25 September 2011 (UTC)- This is a really good idea. --Dianna (talk) 03:07, 16 October 2011 (UTC)
- If you read further up, you'll that for most cases, the hlist class could be applied by default, so instead, adding a parameter could be there to switch the option off rather than on for the occasional case where it doesn't work. -- WOSlinker (talk) 09:32, 16 October 2011 (UTC)
- Although one advantage of switching the option on rather than on by default is that it would be easier to track which navboxes had been converted. On by default could be added later once most navboxes were using flatlists. -- WOSlinker (talk) 09:36, 16 October 2011 (UTC)
- If you read further up, you'll that for most cases, the hlist class could be applied by default, so instead, adding a parameter could be there to switch the option off rather than on for the occasional case where it doesn't work. -- WOSlinker (talk) 09:32, 16 October 2011 (UTC)
- This is a really good idea. --Dianna (talk) 03:07, 16 October 2011 (UTC)
- I would just like to say, I would rather see this named
If I don't hear any more on this in the next few weeks, I'll see about adding a flatlist param. -- WOSlinker (talk) 08:30, 23 October 2011 (UTC)
- As far as I'm aware, the display problems for Flatlist have still not been resolved. When I view {{Edmonton elections}} in IE the dots are still skewed towards the right-hand link, and extra dots still appear at the end of lists (see here). I am not comfortable with this being rolled out further before the problems are fixed. Number 57 09:49, 23 October 2011 (UTC)
- As far as I am aware the display problems are IE's display problems and not Flatlist's display problems. This has been fixed in IE 10 and actually rendered correctly in IE 9 under compatibility mode. It is true many people are using old versions of IE but that hardly means we should bend to that just because a broken browser is popular. Some addition discussion is available here: User talk:Diannaa/Archive 13#Flatlist. Further this has been fixed for mostly of IE versions less than 9 via [1]. 67.210.196.5 (talk) 17:44, 28 October 2011 (UTC)
Usage of "Show/Hide" Outside Navbox Context
Sorry if I'm posting this in the wrong place, but I'd like to use the show/hide feature of the navbox in another context...I want to have a description of an item in a table that's hidden by default and can be revealed by clicking "show." Jmajeremy (talk) 01:04, 25 May 2011 (UTC)
- I'd think the easy way would be to use the navbox template directly? I'm curious as to what the context is, though. → ROUX ₪ 01:06, 25 May 2011 (UTC)
- Here's what I've come up with so far. Not sure if it's "kosher" wikicode, though...
{| class="wikitable sortable" |- ! Header text !! Header text !! Header text |- | {{Navbox|child |state=collapsed |name=cobra |title=The Cobra |navbar=plain |basestyle=background:#ffffff; |abovestyle=text-align:left; |above="hello" }} || Example || Example |- | Example || Example || Example |- | Example || Example || Example |}
Header text Header text Header text The Cobra"hello"Example Example Example Example Example Example Example Example
- If it works, it's kosher. I'm still trying to understand under what circumstances this would be useful though. What is the purpose of this? → ROUX ₪ 03:12, 25 May 2011 (UTC)
- Basically, you can use the show/hide feature on any table by giving it the "collapsible" class. The show/hide link will appear in the first table header. — Edokter (talk) — 13:31, 25 May 2011 (UTC)
{| class="wikitable collapsible" ! colspan="2" | Header |- |Cell 1 |Cell 2 |- |Cell 3 |Cell 4 |}
Header | |
---|---|
Cell 1 | Cell 2 |
Cell 3 | Cell 4 |
Proposal to remove the styling options
As above, I see no reason to keep these options . Wiki doesn't allow projects and users to style articles, we don't let users decide that alternation paragraphs on Manchester United are going to be red and white. Nor do we allow users to define the font type or in vast majority of cases the size. Only in templates is this allowed . WP:COLOUR outlines a number of issues with certain colour combinations, template such as Template:Phantom_of_the_Opera and Sons of Anarchy are unreadable to my eyes, while Giovanni_Trapattoni is a multi coloured mess. I can't think of a reason to keep this option other that WP:ILIKEIT Gnevin (talk) 16:00, 16 June 2011 (UTC)
- I've never used these options, but I see no reason to remove them. If particular templates have issues, address them there. --SarekOfVulcan (talk) 16:22, 16 June 2011 (UTC)
- Oppose. Just because something can be abused does not mean we should remove it alltogether. Styling is also used to adjust margins and padding in certain cases, especially since this is a meta-template. Removing it would break hundreds of navboxes that do not even use colors. — Edokter (talk) — 17:10, 16 June 2011 (UTC)
- Oppose - discreet/subtle styling is useful for linking together thematically-related navboxes, providing clues as to their contents. I agree that many are horrifying eyesores, but let's keep the baby when we drain the tub, shall we? → ROUX ₪ 17:36, 16 June 2011 (UTC)
- Oppose No, people shouldn't be using horrid color combinations in navboxes, but we should not be removing the styling options altogether. Navboxes are used for much more than just articles, and more flexibility should be allowed for projectspace or userspace navboxes. Instead, we should be add to WP:COLOR certain instances when navbox styling is appropriate and not appropriate (e.g., things like padding fixes should be fine, and colors shouldn't be used carelessly). But for many cases, colors are useful for identification. We also have some color elements in infoboxes—perhaps we could standardize things and match them up by subject area? /ƒETCHCOMMS/ 18:11, 16 June 2011 (UTC)
- Oppose — Fix abuses as needed but don't remove the features. Before styling was added, editors were using all sorts of horrible hacks to style elements. Perhaps add a class so someone who hates the colors can remove them in personal CSS. -— Gadget850 (Ed) talk 18:19, 16 June 2011 (UTC)
- Oppose - Tail wagging the dog. If you are having difficulty with specific stylized templates that expand from this, then raise your concern with them. Otherwise please collect a affirmative response from every usage of this template acknowledging that they're Ok with the removal of the stylizing options. When you are attempting to take some flexibility away from users you really should get consent from everyone as people expect software to work the same unless they've been notified prior to usage about it. Hasteur (talk) 18:43, 16 June 2011 (UTC)
- Support the core idea but oppose the methodology. I completely agree that we need to do something about the massive wp:deviations just for the sake of "I like it" and "it looks pretty". However, as has been pointed out above, there these style fields are used for more than just colouring. We should create a task force to try to remove the superfluous deviations in colouring, but, this is something which cannot be simply addressed at the level of this template. Frietjes (talk) 23:23, 16 June 2011 (UTC)
- I've only ever seen the style used for colouring , can you give some examples of the other behavour it addresses Gnevin (talk) 23:46, 16 June 2011 (UTC)
- Comment I'd challenge those above to show me a case where the use of the style para has led you to say wow this really improves the project. This isn't about indivual cases I don't like, even perfectly good templates when combined can look terrible and present access issues. This para should improve the project, it doesn't Gnevin (talk) 23:46, 16 June 2011 (UTC)
- That's twisting the point. The style parameter doesn't have to make me say "wow". Without it, I would say "ew" if messy margins or widths ensued. Again, I think you're focusing on the wrong thing here: the problem is not the parameter's existence. It is people misusing the parameter or making poor choices with what they put in it. So you should instead be formulating a clear guideline for what is appropriate usage of the parameter. /ƒETCHCOMMS/ 19:53, 17 June 2011 (UTC)
- Oppose - Trying to button things down past a certain point leads to stultifying conformity and blandness. Some deviation should be seen as a positive value. It provides wriggle room around the edges for some creativity and diversity; perhaps even a little colour. Wikipedia already has very bland and uninteresting default formats. Take this further and Wikipedia will start looking like something out of an apparatchik's dream (nightmare?). --Epipelagic (talk) 02:02, 17 June 2011 (UTC)
- Oppose - While I also prefer standardized colors and styles, I must agree with Edokter that the styling parameters are often used for things other than color, such as width and padding. Removing them would break many hundreds or thousands of templates. --CapitalR (talk) 09:41, 17 June 2011 (UTC)
- Oppose per Roux. Unusually, it appears to be snowing in June.—S Marshall T/C 11:01, 17 June 2011 (UTC)
- Support the idea Remove the ability for gaudy color choices and implement a non-gaudy color palette throughout, removing the instances of the horrendous color combinations as demonstrated above. The problem with Fix abuses as needed but don't remove the features. is that there are so many instances of the abuse, particularly on sports pages. Perhaps create a task force to remove the superfluous deviations in coloring as suggested above. --Bob (talk) 22:41, 17 June 2011 (UTC)
- Comment This parameter is being used for more than colouring as as such removing isn't a realistic option. However I'm still interested in working with those who agreed that this needs to be fixed Gnevin (talk) 00:23, 19 June 2011 (UTC)
- Oppose based on everything said in opposition to this proposal, above.
— V = IR (Talk • Contribs) 05:58, 19 June 2011 (UTC) - Oppose Colorization is quite useful for identification purposes. If a particular navbox's color scheme is horrible, then fix that navbox. --Cybercobra (talk) 22:40, 19 June 2011 (UTC)
- Oppose per SarekOfVulcan. And I like the Idea of Gadget850 to add a class so someone who hates the colors can remove them in personal CSS Reo + 13:55, 20 June 2011 (UTC)
- This isn't about people hating colours. Its about improving the project Gnevin (talk) 00:04, 22 June 2011 (UTC)
- Oppose while conceding that the Giovanni Trapattoni managerial positions is jarring when opened. I guess I'm one of those sports people that loves them colors, but when I open the championships etc navbox on Diana Taurasi, the colors are a useful guide. Anyone who follows the sport will recognize the National Flag Blue associated with UConn, will recognize the team colors of the Phoenix Mercury, and the red of Spartak Moscow. It may come across as garish to someone who doesn't follow the sport, but most will make sense to people likely to look at it. As an aside, I have a personal rule to create a collapsed navbox whenever the number reaches five, partly to keep potential garishness to a reasonable level.--SPhilbrickT 20:36, 24 June 2011 (UTC)
- Oppose if Giovanni Trapattoni is the problem, fix Giovanni Trapattoni, don't try to disable the whole machine because of a few excesses. Justlettersandnumbers (talk) 23:29, 24 June 2011 (UTC)
- Oppose - Per SOV and Fetchcomms, also wouldn't this mess up thousands of pages with the template ? Mlpearc powwow 23:43, 24 June 2011 (UTC)
Suggested guidelines
Wikipedia_talk:Manual_of_Style_(text_formatting)#Colour I've suggested some guidelines, opinions welcome Gnevin (talk) 00:27, 22 June 2011 (UTC)
Not working despite instructions
I'm in the process of setting up a 1.16 wiki and am trying to copy some of these templates over. I've installed ParserFunctions as well as the provided common.js and common.css (which I know work due to some other templates). Also, I'm using the modified transwiki version which shouldn't require html tidy.
I cannot for the life of me get Navbox to work right. Viewed on my wiki, it appears as:
{ | class="navbox" cellspacing="0" style=";" |- | style="padding:2px;" | { | cellspacing="0" class="nowraplinks " style="width:100%;background:transparent;color:inherit;;" |}
Any ideas what my problem is? TheGreatTK 17:37, 20 June 2011 (UTC) — Preceding unsigned comment added by TheGreatTK (talk • contribs)
- Do you have an example of what your trying to achieve ? Mlpearc powwow 12:51, 25 June 2011 (UTC)
added two more examples
titlestyle -
a CSS style for the title-bar, Two examples:- Used with Template:Navbox suite:
|titlestyle = background:#00529b;color:white;border:2px solid #00529b;
|titlestyle = background:gray;
- Used with Template:Navbox suite:
groupstyle -
a CSS style for the group-cells, Two examples:- Used with Template:Navbox suite:
|groupstyle = background:#febd10;color:#00529b;border:2px solid #febd10;
|titlestyle = background:#eee;
- Used with Template:Navbox suite:
Errectstapler (talk) 19:11, 17 July 2011 (UTC)
- {{Navbox suite}} does not use these parameters (it was vandalized), so I removed the examples. — Edokter (talk) — 19:22, 17 July 2011 (UTC)
Is there any way to remove the autocollapsible feature in templates based on this one?
Asked in 2008:
- == Is there any way to remove the autocollapsible feature in templates based on this one? ==
Please respond on my talk page if you know.`Savidan 17:18, 9 August 2008 (UTC) ...
- |state = plain will not collapse the navbox and hide the show/hide link. — Edokter • Talk • 22:03, 9 August 2008 (UTC)
Not sure the answer, but |state = plain does not hide the show/hide link.
Any other suggestions, thank you. Errectstapler (talk) 22:50, 17 July 2011 (UTC)
- oh nevermind, |state = plain does work, i had it listed twice and the template only reads the last state line. Errectstapler (talk) 22:55, 17 July 2011 (UTC)
Latest update
I think the latest update messed up the navboxes containing wrap codes. See this one for example: Template:Dioceses of the_Church of the East.--Rafy talk 15:10, 21 July 2011 (UTC)
- I don't see anything wrong. What is the problem? — Edokter (talk) — 15:22, 21 July 2011 (UTC)
- I never had an issue using various Linux distros, but I lately had to use Win7 and I'm unable to view the items on the template with Firefox (Here is a screenshot). They are however visible with Chrome, Opera and IE. Can anyone else confirm this?--Rafy talk 17:32, 21 July 2011 (UTC)
- Shows OK on XP with Firefox 5.0. — Edokter (talk) — 19:50, 21 July 2011 (UTC)
- OK on Win7 with Fx 4.0. What browser version are you using? Fx 5 or 4? --Izno (talk) 23:08, 21 July 2011 (UTC)
- Latest stable (5).--Rafy talk 23:26, 21 July 2011 (UTC)
- I never had an issue using various Linux distros, but I lately had to use Win7 and I'm unable to view the items on the template with Firefox (Here is a screenshot). They are however visible with Chrome, Opera and IE. Can anyone else confirm this?--Rafy talk 17:32, 21 July 2011 (UTC)
Child causes HTML error
The use of |child=
causes an HTML validation error, for example {{navbox}}
Renders as
Which cause an error on this page; see W3C markup validation for Template talk:Navbox. ---— Gadget850 (Ed) talk 01:45, 24 August 2011 (UTC)
- I don't think this has anything to do with Navbox. It looks like this is happening for all Vector-skin pages (at least for me). If you look at the source, it appears to be in the Vector menu and is because of an empty <ul></ul> pair. I just tested it out and this happens regardless of whether there's a Navbox or not. I use Monobook by default, and the problem doesn't manifest for that skin. --CapitalR (talk) 00:14, 26 August 2011 (UTC)
- I should have noted that the
<ul>
issue has been occurring for ages. I did not use a live use of {{navbox}} in my example— this has been updated. The error in question isend tag for "table" which is not finished
. ---— Gadget850 (Ed) talk 00:40, 26 August 2011 (UTC)
- I should have noted that the
- It's because if you just use {{navbox|child=xxx}}, you end up with a <table></table> set of tags. If you actually put in some content such as list1=a then the table tags are no longer empty and so pass validation. -- WOSlinker (talk) 07:04, 26 August 2011 (UTC)
- I thought I had tracked it here, but perhaps I'm wrong. Pages that are giving this error:
- Template:Navbox with collapsible groups/doc; W3C markup validation for Template:Navbox with collapsible groups/doc
- {{Free Imperial Cities}}; W3C markup validation for Template:Free Imperial Cities
- {{IPA navigation}}; W3C markup validation for Template:IPA navigation
- ---— Gadget850 (Ed) talk 11:05, 26 August 2011 (UTC)
- I thought I had tracked it here, but perhaps I'm wrong. Pages that are giving this error:
- I think this edit has fixed the issue. -- WOSlinker (talk) 11:37, 26 August 2011 (UTC)
- Those pages are still failing validation. ---— Gadget850 (Ed) talk 11:44, 26 August 2011 (UTC)
- Probably just due to cacheing. I've purged the pages and I'm only seeing the two ul errors myself. -- WOSlinker (talk) 12:53, 26 August 2011 (UTC)
Fixed That did it. Thanks. ---— Gadget850 (Ed) talk 13:09, 26 August 2011 (UTC)
- Probably just due to cacheing. I've purged the pages and I'm only seeing the two ul errors myself. -- WOSlinker (talk) 12:53, 26 August 2011 (UTC)
Help importing this template to the spanish wiki
There's a watered down version of this template in the spanish wiki, but in order to use the "subgroup" template, you must have the english wikipedia code of the navbox template. I've been trying to copy and paste the code from this wikipedia, to the spanish wiki. It works, sort of though... here's an examlple: es:Plantilla:Navegación/núcleo2/test, I haven't figured out yet what's not working properly... and I can't seem to fix it. The "subgroup" template in the spanish wiki is a direct copy from the english wiki... so basically both the navbox and subgroup codes are identical (I deleted the navbar code, but even if left on, the same problem occurs).
Navbar code in the spanish wiki: es:Plantilla:Navegación/núcleo2
Subgroup code in the spanish wiki: es:Plantilla:Navegación/subgrupo.
The code I'm using in the "test" is also a direct copy from the enlgish wiki.
Am I doing something wrong? Or is it that the spanish wiki doesn't support some parts of the code? Thanks for your time. --MindZiper (talk) 00:31, 26 September 2011 (UTC)
- Hi MindZiper -- the Navbox template depends on some CSS located in MediaWiki:Common.css (just look for the navbox section there). Without that CSS on the Spanish wiki the template will look a little odd and not be properly formatted. --CapitalR (talk) 08:12, 26 September 2011 (UTC)
- Is there a way to import the code needed for the navbox into the spanish wiki? I don't seem to find any "link" that directs to that code in particular within the navbox code. EDIT: I think I got it. --MindZiper (talk) 01:32, 27 September 2011 (UTC)
Flatlist problems
A template I watch was recently converted to flatlist. When viewed in any version of IE, it creates several problems, most notably the major misalignment of the dots and the addition of an extra dot after the end of the list (example below). Can anyone help solve this? Unfortunately the only answers I've had so far is to question why I've chosen to use the wrong browser (IE, the most commonly used one in the world), to have to switch to compatibility view (which works, but I don't see why readers should have to do this, and it isn't available on older versions of IE), and to say that Microsoft should solve the problem. In the meantime I've been told to just put up with the problem rather than revert to the issue-free version - is this acceptable? Number 57 08:55, 1 October 2011 (UTC)
- Which version of IE do you use? I've just tried Template:Edmonton elections in IE 8 & 9 and it looks fire for me. -- WOSlinker (talk) 09:24, 1 October 2011 (UTC)
- It has the problem when viewed in IE8 on Win XP. GraemeLeggett (talk) 09:29, 1 October 2011 (UTC)
- Except for the trailing dots (due to IE's lack of support for
:last-child
), I see no allignment issues on IE8 (XP), except when enabling compatibility view. — Edokter (talk) — 10:10, 1 October 2011 (UTC)- This is how it displays in IE8 and compatibility mode doesn't help much.
![](http://upload.wikimedia.org/wikipedia/en/0/05/Edmonton-IE8.png)
- However IE9 in compatibility mode is more standards-compliant, i.e. it understands the :last-child css selector and can format the last item in a list as required. However, IE9 requires a HTML5 doctype declaration to automatically change to compatibility mode, so you have to click the button manually.
- The so-called "issue-free version" is the one where Number 57 has no issues, but all of our visually-impaired visitors have to hear things like "1892, dot, 1893, dot ..." etc. It doesn't meet our standards for accessibility, and I'm disappointed that Number 57 prefers to force that version on disabled visitors rather than click a button or use a standards-compatible browser. I'm sorry he doesn't like the replies he's had from me, but it would be far better to seek a consensus than to edit-war to impose a preferred version. Perhaps others here can suggest possibilities that would address both the issues of accessibility and Number 57's concerns? --RexxS (talk) 10:31, 1 October 2011 (UTC)
- Just read the WP:Accessibility notes and in referring to templates such lists may be styled with the class "horizontal". Not being up on the coding, what would that do if used instead of flatlist in this case?
- Sadly, it won't help because {{Flatlist}} is effectively a convenience to apply the class .hlist (an updated version of class .horizontal) to a list, to save editors from having to deal with classes. The problem is that our css definition of the class .hlist in MediaWiki:Common.css relies on a css feature to identify the last item in a list and suppress the image of the dot. Microsoft failed to implement that feature until version 9 of Internet Explorer, although it has been available in all the other common browsers for some considerable time. It is a problem that will go away eventually as Microsoft brings its browser into line with universally accepted web standards. In the meantime, any ideas for avoiding problems such as concern Number 57 would be welcome, as long as they don't sacrifice accessibility for disabled viewers. One earlier suggestion for {{Flatlist}} was to put the dot before each item and suppress the dot on the first item (Internet Explorer 7 & 8 are capable of selecting the first item, but not the last!). However, this had the undesirable effect, when a long list wrapped onto a new line, of having the new line start with a dot – and consensus went against that. --RexxS (talk) 12:25, 1 October 2011 (UTC)
- Just read the WP:Accessibility notes and in referring to templates such lists may be styled with the class "horizontal". Not being up on the coding, what would that do if used instead of flatlist in this case?
- The so-called "issue-free version" is the one where Number 57 has no issues, but all of our visually-impaired visitors have to hear things like "1892, dot, 1893, dot ..." etc. It doesn't meet our standards for accessibility, and I'm disappointed that Number 57 prefers to force that version on disabled visitors rather than click a button or use a standards-compatible browser. I'm sorry he doesn't like the replies he's had from me, but it would be far better to seek a consensus than to edit-war to impose a preferred version. Perhaps others here can suggest possibilities that would address both the issues of accessibility and Number 57's concerns? --RexxS (talk) 10:31, 1 October 2011 (UTC)
- "selectivizr is a JavaScript utility that emulates CSS3 pseudo-classes and attribute selectors in Internet Explorer 6-8. Simply include the script in your pages and selectivizr will do the rest."
:last-child
is listed. Might be worth checking out. ---— Gadget850 (Ed) talk 13:41, 1 October 2011 (UTC)- This may work, but I think it is the wrong kind of solution. We should not be telling readers/editors to download special scripts so they can see things correctly - we should make templates that everyone can view correctly regardless of their browser type. Number 57 22:15, 1 October 2011 (UTC)
- Readers/editors wouldn't need to. But I believe we should not depend on scripts too much. Personally, I still favor putting the bullet in front of the items; it is a list after all. So I think we need to explore that option again. — Edokter (talk) — 22:20, 1 October 2011 (UTC)
- This may work, but I think it is the wrong kind of solution. We should not be telling readers/editors to download special scripts so they can see things correctly - we should make templates that everyone can view correctly regardless of their browser type. Number 57 22:15, 1 October 2011 (UTC)
- "selectivizr is a JavaScript utility that emulates CSS3 pseudo-classes and attribute selectors in Internet Explorer 6-8. Simply include the script in your pages and selectivizr will do the rest."
- I just saw Template talk:Flatlist#Viewing problems, just below a prior suggestion I'd made: Template talk:Flatlist#Nested list, again. Issues with Internet Explorer are common, as it is known for quirky behavior and poor CSS support. This seems a minor rendering issue with a buggy (and obstinant) browser, really. The accessibility benefits of flatlist far outweigh a few off-pixels. IE users have options: Incompatibility mode, to downloading a better browser. Beyond the vision impaired, there are many sighted mobile users that benefit from nav-lists /being/ lists, as flatlist offers.
- FYI, the /Nested list, again/ suggestion I made was about getting pseudo-groups (i.e. nested lists) to work inline using
.hlist li ul { display: inline; }
; help with that idea would be appreciated. It would also be nice to get the nowrap adjusted to make whole li-tags not wrap — things like "* book title (year)
". Something like:.hlist li { white-space: nowrap; }
. - I'd be wary of putting the middots /before/ items as these are really interpunct, not bullets; such punctuation logically follows, not precedes. Dots at the beginning of wrapped lines would be unfortunate. The padding/margin values used w/flatlist may be able to be tweaked to get more consistent rendering—if so, fine—but deployment of flatlist should not be thwarted. —Portuguese Man o' War 23:09, 1 October 2011 (UTC)
- I fail to understand why some editors think the answer is to tell others that they need to download a new browser because some changes they've made don't work in IE - it smacks or smugness and arrogance. Like it or not, IE is the most common browser used, and you can't ask over 40% of internet users to change their browser because someone can't get the code to work. Number 57 23:24, 1 October 2011 (UTC)
- Offering the idea of other browsers is /helpful/. This is a failing of IE's code, not the flatlist/hlist code (which isn't mine). The code in use here, is good, standards-compliant code, that IE is improperly rendering. You seem intent on restricting wiki to the capabilities of the least capable browser. Please don't; a few off-pixels is no big deal.
- (ec; re; 'you') —Portuguese Man o' War 23:39, 1 October 2011 (UTC)
- I fail to understand how some people can hang on to outdated software, and seemingly expect the rest of the world to cease progressing. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 19:45, 15 October 2011 (UTC)
- I fail to understand why some editors think the answer is to tell others that they need to download a new browser because some changes they've made don't work in IE - it smacks or smugness and arrogance. Like it or not, IE is the most common browser used, and you can't ask over 40% of internet users to change their browser because someone can't get the code to work. Number 57 23:24, 1 October 2011 (UTC)
I've had a good search to see how the javascript modules do the job of emulating :last-child. After much trial and error in my monobook.css, I have a slight improvement available for IE8 in compatibility mode:
.hlist li {background-image: expression(this.nextSibling==null?'none':'');} .hlist li {padding-right: expression(this.nextSibling==null?'0em':'0.4em');} .hlist li {margin-right: expression(this.nextSibling==null?'0em':'0.2em');}
You can paste it into your own local css and see how (badly) it works in your version of Internet Explorer. Without compatibility mode, IE8 displays cleanly, but with the dot at the end of each list as before. In compatibility mode, IE8 evaluates the 'expression' syntax and clears the final dot. Other browsers ignore that, so are unaffected by the declarations. I've had to jigger the right-padding & right-margin to make it look similar to other browsers, but sadly IE8 in compatibility mode doesn't maintain a right-padding against the right border of a container, so it may squash the dot into the text at the end of each line that wraps. Ugly, but that's MS for you. It would be interesting to see how this shows up in IE9 in compatibility mode, but I haven't checked yet. --RexxS (talk) 00:15, 2 October 2011 (UTC)
- It doesn't seem to hurt any, although I run Chrome using Internet Explorer Immunity Mode. Good luck with it. —Portuguese Man o' War 00:43, 2 October 2011 (UTC)
- @Rexx: I have tried this out on my laptop in IE9, and it looks fine when I load the page. When I switch to compatibility mode, the dot at the end of each line is squished against the text.
- @Number 57: You might be interested to know that there are rounded corners, shadows, and eye-popping things on my user page and talk page which you are missing out on, as they don't appear in IE. I am now returning to Firefox. Regards, --Dianna (talk) 07:43, 2 October 2011 (UTC)
- (Off-topic) Dianna, you may want to check out {{border-radius}} and {{box-shadow}} for cross-browser eye-candy support for your user page. — Edokter (talk) — 07:54, 2 October 2011 (UTC)
- Thanks. I think I will try out the gradient :) --Dianna (talk) 14:47, 2 October 2011 (UTC)
- (Off-topic) Dianna, you may want to check out {{border-radius}} and {{box-shadow}} for cross-browser eye-candy support for your user page. — Edokter (talk) — 07:54, 2 October 2011 (UTC)
Partial fix
I've added one line of javascript to Common.js that at least removes the trailing dot from the last list item in IE 6, 7 and 8. So far, nothing I can do about the misallignment of the dots in IE8's compatibility mode. — Edokter (talk) — 17:00, 24 October 2011 (UTC)
Semantic and accesssible list markup, redux
May I refer fellow editors to Semantic and accesssible list markup, above which seems to have stalled? Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 19:42, 15 October 2011 (UTC)
aligning navbox columns with children
To eliminate duplication of content, I made a few child navbox templates that integrated into parent templates like this:
However, the columns weren't perfectly aligned, so another user copied and pasted the child templates back in. Is there some way we could get both features at the same time? --Joy [shallot] (talk) 17:06, 26 October 2011 (UTC)
- currently the only way I know of how to get them to have the same size, is to pass a "groupwidth" parameter. it would be great if it were possible to have the children all automatically have the same width, but right now they are technically in separate html tables, so that is not possible. Frietjes (talk) 19:01, 26 October 2011 (UTC)
- I infer from this that the groupwidth parameter can't take any value other than in em's or px's, which isn't compatible with varying font widths per se? I'm not sure if that's unacceptable in the general use case - the result seems to render fine for me no matter how much I do Ctrl+plus/Ctrl+minus - I know that doesn't emulate all the various resolutions, but still. Can you check? --Joy [shallot] (talk) 10:32, 27 October 2011 (UTC)
- the em units should resize when the font is resized, but as we know what happens with varying browsers ... I think the best solution would be to have the subtemplates generate the table rows, but not the table around it, and then the parent template would generate the containing table. This would require some changes though to make this work. Frietjes (talk) 17:42, 27 October 2011 (UTC)
- I think that would be very convoluted, and even this change didn't fit well with User:Number 57, so I'm wary of extending the technical issue into another twist. --Joy [shallot] (talk) 07:58, 28 October 2011 (UTC)
- on my browser (Firefox, Linux) the groupwidth=16em is perfect, but the 15em is still a bit ragged. Frietjes (talk) 17:44, 27 October 2011 (UTC)
- In the meantime, I reduced the text length as well as the groupwidth. Can you check Template:Elections in Austria-Hungary again please? :) --Joy [shallot] (talk) 07:56, 28 October 2011 (UTC)
- yes, that looks perfect on my browser. Frietjes (talk) 15:20, 28 October 2011 (UTC)
- In the meantime, I reduced the text length as well as the groupwidth. Can you check Template:Elections in Austria-Hungary again please? :) --Joy [shallot] (talk) 07:56, 28 October 2011 (UTC)
- the em units should resize when the font is resized, but as we know what happens with varying browsers ... I think the best solution would be to have the subtemplates generate the table rows, but not the table around it, and then the parent template would generate the containing table. This would require some changes though to make this work. Frietjes (talk) 17:42, 27 October 2011 (UTC)
- I infer from this that the groupwidth parameter can't take any value other than in em's or px's, which isn't compatible with varying font widths per se? I'm not sure if that's unacceptable in the general use case - the result seems to render fine for me no matter how much I do Ctrl+plus/Ctrl+minus - I know that doesn't emulate all the various resolutions, but still. Can you check? --Joy [shallot] (talk) 10:32, 27 October 2011 (UTC)
Category changes
In this CfD nomination, I've suggested changing all of the content-based navbox category names to Category:(X) navigational boxes. We've been heading that direction in the last few weeks, and I'd like to see it done automatically so that the category names aren't quite so wildly different. Please comment over at CfD if you have opinions on this.--Mike Selinker (talk) 09:52, 28 October 2011 (UTC)
Problems with "best practice"
Hi, template edits made here and here with summary like "update to best practice" have messed up the formatting, at least in IE8. Example "before and after" screenshots from IE are here. As you can see, while the old version is fine, the bullets, or interpuncts, or whatever they are, look horrible in the new version.
Unless there are worse problems with the old format that I am not seeing (e.g in other broswers), my feeling is that these changes need to be undone wherever they have been implemented, and any claim anywhere that they are "best practice" needs to be removed. I am raising it here in case it is a widespread problem or problem in the making. Regards, 86.177.108.207 (talk) 03:35, 10 November 2011 (UTC)
- There is a simple solution: at the top of your browser bar there is an icon that looks like a ripped piece of paper. Click on that button, and Internet Explorer will enter or leave "Compatibility Mode". This is a hack that Internet Explorer has added to their software to get it to display images correctly. Click on the little icon in IE8 and you will exit Compatibility Mode, and the template will then display correctly. Microsoft has fixed the problem for IE10, and IE9 is displaying correctly after the recent upgrades to the MediaWiki software. --Dianna (talk) 05:57, 10 November 2011 (UTC)
- That icon is not displayed for a sample of affected pages that I have just checked. Additionally, I have noticed that pages are now showing new-style navboxes without any line-wrapping, with the result that take up an enormous width, and require a great deal of ugly horizontal scrolling to navigate the links. A typical example is the "Polar Exploration" box at Northwest Passage. I have not seen this with old-style navboxes, so I am assuming (without absolute proof) that it is all part of the same problem.* Unless a specific decision has been made that IE8 is not to be supported, these issues need to be fixed, and if they can't be fixed promptly then we need to roll back to the old navbox formatting. 109.151.34.223 (talk) 20:31, 10 November 2011 (UTC)
- * Further, the page Template:American_Civil_War shows the bullet formatting problem but not the no-line-wrap problem. However, in situ in the article Abraham Lincoln, the box shows both problems (bullet formatting and huge horizontal extent). I'm not technical enough to have a clue what is going on, but if you want me to test any other examples I will be happy to do so. 109.151.34.223 (talk) 20:50, 10 November 2011 (UTC)
How to implement flatlist?
I have added the listclass parameter. This will eliminate the need for using {{flatlist}}. The only thing needed to produce horizontal lists is to add listclass = hlist to your navbox, and it will automatically format the list cells as horizontal lists. — Edokter (talk) — 09:07, 10 November 2011 (UTC)
- This is excellent. It needs adding to the siblings of navbox and to be passed through from things like {{military navigation}}. Flatlist is not just used in nav-list; it's in groups, above, and below, and this seems to need some extending for that. Here, belowclass = hlist didn't work; I had to go back to flatlist for the below. Here, I would need support for 'group', and in {{navbox with collapsible groups}}. Thanks. Alarbus (talk) 13:07, 10 November 2011 (UTC)
- You can also use bodyclass = hlist to make every list horizontal. — Edokter (talk) — 13:10, 10 November 2011 (UTC)
- I discovered below does not start on a new line, making the first list item fail. I'm not so sure about having lists in group though. — Edokter (talk) — 13:15, 10 November 2011 (UTC)
- fyi (maybe you could check group4? I'm concerned about 'Sovereign Military Order of Malta' — see also)
- See my post on talk:common.css; Template:American Civil War is using flatlist in horizontal groups; this is common, although most are still using the dot-template method. I saw that the first '*' was showing in the below example, which would seem a parsing problem; not at the beginning of the line would do it. You looking somewhere in the implementaions, right; fixable? Alarbus (talk) 13:25, 10 November 2011 (UTC)
- Should be fixed now; below now start on a new line, and {{navbox with collapsible groups}} now passes all classes. — Edokter (talk) — 13:35, 10 November 2011 (UTC)
- Works for me. Thanks; gotta go. Will look-back later. And will push some other other stuff along. See {{Europe topic}}. Alarbus (talk) 13:38, 10 November 2011 (UTC)
- I was reverted on Europe topic, so... more eyes. Alarbus (talk) 14:06, 10 November 2011 (UTC)
- Please ask why you were reverted; I could see no adverse effects. — Edokter (talk) — 14:20, 10 November 2011 (UTC)
- Done. And do have a look at the un-reverted group4 code; I was unsure about the Malta bits. Alarbus (talk) 14:34, 10 November 2011 (UTC)
- I've added listclass param pass-through to {{Military navigation}} & {{Campaign}} -- WOSlinker (talk) 19:09, 10 November 2011 (UTC)
- Done. And do have a look at the un-reverted group4 code; I was unsure about the Malta bits. Alarbus (talk) 14:34, 10 November 2011 (UTC)
- Please ask why you were reverted; I could see no adverse effects. — Edokter (talk) — 14:20, 10 November 2011 (UTC)
- I was reverted on Europe topic, so... more eyes. Alarbus (talk) 14:06, 10 November 2011 (UTC)
- Works for me. Thanks; gotta go. Will look-back later. And will push some other other stuff along. See {{Europe topic}}. Alarbus (talk) 13:38, 10 November 2011 (UTC)
- Should be fixed now; below now start on a new line, and {{navbox with collapsible groups}} now passes all classes. — Edokter (talk) — 13:35, 10 November 2011 (UTC)