Template talk:Navbox

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, in my opinion. 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)

Compatibility view is disastrous. Anyway, if you cannot see the compatibility view button, go to Page or Tools, then go to Compatibility View Options and remove wikipedia.org from the list. That should fix all display issues. — Edokter (talk) — 20:54, 10 November 2011 (UTC)

Thanks, but unfortunately I don't see wikipedia.org listed there. What is "disastrous" (in a limited sense of the word), in my opinion, is that something apparently being touted as "best practice" breaks badly in what is still, I believe, a very commonly used browser. I personally don't think it's acceptable that the user should have to make any special browser fixes or adjustments when they have such a mainstream setup. I very much hope, amongst the technical people who could actually diagnose this, this isn't going to become another case of "don't use that browser, don't care". 109.151.34.223 (talk) 21:32, 10 November 2011 (UTC)

I agree with your sentiments completely. Wikipedia should serve everyone (including those with IE) instead of just those it would like to have (i.e. those without IE). I'm not keen on having pages render improperly by default on such a common browser. Very few will take the time to investigate the reason and change compatibility modes or whatever; instead they'll just believe it's a Wikipedia bug. Unfortunately, as you can see in discussions above, we're in the minority on this view. --CapitalR (talk) 21:53, 10 November 2011 (UTC)

Though the added accessibility benefit of hlist and flatlist does count for something. --CapitalR (talk) 21:55, 10 November 2011 (UTC)

It may be that the "Display all website in Compatibility View" box is ticked. Would be nice if the "X-UA-Compatible" meta tag could be added to the wikipedia site. -- WOSlinker (talk) 22:17, 10 November 2011 (UTC)

That would limit features to one specific IE version, not a good idea. What needs to be done is change the doctype to HTML5. This was done a short while ago, but was reverted later; I forgot the reason. — Edokter (talk) — 22:35, 10 November 2011 (UTC)

See Wikipedia:Wikipedia Signpost/2011-02-28/Technology report. ---— Gadget850 (Ed) ^talk 12:56, 11 November 2011 (UTC)

Can use <meta http-equiv="X-UA-Compatible" content="IE=edge"> in that case. -- WOSlinker (talk) 12:44, 11 November 2011 (UTC)

Wikipedia.org should not be viewed in compatibility mode in the first place. Do you have IE8 or IE9? — Edokter (talk) — 22:11, 10 November 2011 (UTC)

I'm using IE8. In IE "Compatibility View Settings" window I see:

Websites you've added to Compatibility View: Empty

Include updated website lists from Microsoft: Checked

Display intranet sites in Compatibility View: Checked

Display all websites in Compatiblity View: Unchecked

As far as I'm aware, I have never changed any of these settings. 109.151.34.223 (talk) 22:59, 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)

A mistake. Alarbus (talk) 03:17, 11 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)

Thanks (and re Europe topic). I'll give those a try. Anyone seeing what this was about? Alarbus (talk) 03:17, 11 November 2011 (UTC)

Here is another instance of the listclass parameter causing incorrect display: Diff of Template:Noticeboard links. The problem is not discernible in my browser but we need to find out what's going on. --Dianna (talk) 05:21, 11 November 2011 (UTC)

The diff I gave did not involve listclass or bodyclass, just flat list. And Djmaschek has replied to me, said two machines. Bad Browser, I expect; they've been retarding the internet forever.

• To Hell With Bad Browsers

Alarbus (talk) 05:37, 11 November 2011 (UTC)

Bodyclass is actually a little cheaper on resources (post-expand include size and template argument size); I did a comparison using the big template {{Universe navboxes}}. Jayron32 changed the template in the above diff to bodyclass, so perhaps bodyclass is the way to go --Dianna (talk) 05:52, 11 November 2011 (UTC)

I'm wondering if just having all navboxes be of class hlist out-of-the-box would be the best option. If any specific template is not using */# lists, the class will simply have no effect. Alarbus (talk) 06:15, 11 November 2011 (UTC)

Deindent: We discussed that above, and the reason why that's not the case is, at the least Template:Navbox with columns... --Izno (talk) 09:50, 11 November 2011 (UTC)

Also, the advantage of a parameter is that its then possible to see what has been converted and what has not with the use of a tracking category. -- WOSlinker (talk) 09:57, 11 November 2011 (UTC)

Inzo; you really want ordinary bulleted lists in nav w/cols? I suppose that one could be left requiring a class be passed (not keen on an oddity, though). My thinking was that making it the default would streamline millions of navboxes and reduce the template-parsing burden. I read about the ketamine issue.

WOSlinker; the class-parms are a parsing burden, too. My understanding is that the endless {dot} templates are a page-generation-time and page-size-limiting issue; the templates like {nowrap begin/end}, too. {flatlist} was less of a burden, but less-yet would be better-yet. Would not more code in {navbox} to generate a tracking category similarly be prohibitively expensive? (and if not, let's have it.)

Anyway, a few people are still seeing width issues and that needs better understanding. Night w did something to {Europe topic}, again (and some others), which I'll peek at in a moment. Alarbus (talk) 10:21, 11 November 2011 (UTC)

Can you document this properly in the template documentation please? --Joy [shallot] (talk) 11:31, 11 November 2011 (UTC)

Wrapping issues

The wrapping issues noted by Jayron32 and others are due to IE's "Compatibility" view (irony intended). The reason why bodyclass seemed unaffected is because of a (now fixed) CSS coding mistake. At the moment, {{flatlist}}, bodyclass and listclass in navboxes now all produce the same broken wrapping behaviour in Compatibility view. There is only one solution: turn off Compatibility view for Wikipedia. — Edokter (talk) — 12:09, 11 November 2011 (UTC)

I can't turn off compatability mode. Websites that I use whilst editing don't display properly. Nightw 13:29, 11 November 2011 (UTC)

Do you have examples? We can't fix compatibility view issues, but perhaps we can fix issues in standards view. — Edokter (talk) — 13:40, 11 November 2011 (UTC)

Examples of websites? If you can't fix compatibility view issues, I don't see how it matters. Surely this creates an accessibility problem? If you've got multiple editors saying they now can't see things properly, there are going to be lots of readers who see the same problem but won't know how to fix it. This needs to be brought up at WT:ACCESS to determine if this is indeed an improvement. Nightw 14:14, 11 November 2011 (UTC)

This originated with those folks. Alarbus (talk) 14:24, 11 November 2011 (UTC)

I see Rexx. I don't see any of the other access gurus. As seen, it's having an immediate impact on accessibility. I'm saying it needs the consensus of the wider community to determine how this is going to affect casual readers. Nightw 14:35, 11 November 2011 (UTC)

And see User:Pigsonthewing, above, at: #Semantic and accesssible list markup, and elsewhere on this page. Alarbus (talk) 14:43, 11 November 2011 (UTC)

I see that. That's two then. Nightw 14:48, 11 November 2011 (UTC)

Re: Flatlists: as I've said before, as a screen reader user, I think that semantically valid HTML lists are nice to have, but not a high priority ... especially if they break the look of a page for people using a very common browser. But some people disagree with me, naturally. Re: Compatibility mode, Sometimes IE8 accesses that mode automatically on certain Wikipedia pages, unless users change the default settings. Graham87 14:53, 11 November 2011 (UTC)

Good semantic structure is helpful for more than screen reader users; web spiders, for example. The list format in the editbox is far more accessible for ordinary editors, too; far easier to read, to maintain. There's also a huge performance cost to all these {dot} templates; see Talk:Ketamine#Too many templates!. Without the {dot} templates and the {nowrap} stuff, pages will be generated far faster for everyone. If IE's going have these kooky modes, IE users are going to have to switch between them. Alarbus (talk) 15:14, 11 November 2011 (UTC)

IE remembers compatibility settings per website. So you can turn it of for Wikipedia while leaving it on for other websites. — Edokter (talk) — 15:00, 11 November 2011 (UTC)

Wholesale reverts

I strongly urge that we stop making these formatting changes to navboxes unless and until the IE problems are resolved. I have just come across another recently changed one at Template:Spaceflight_lists_and_timelines, which I have reverted. Not only are the bullets messed up and ugly, the line-wrapping doesn't work, with the result that the navbox appears enormously wide. It truly is a terrible mess, and unacceptable unless there has been a high-level decision that we are deliberately not properly supporting whichever versions of IE are affected. 86.176.212.32 (talk) 00:55, 12 November 2011 (UTC) (BTW, I can't relate to the above mentions of turning off IE compatability view. AFAIK, IE displays a "broken page" icon when in compatibility view. I do not see this when in Wikipedia, and I have no other indication that IE is in compatibility view, or any known way to turn it off if it is.) 86.176.212.32 (talk) 01:05, 12 November 2011 (UTC)

The button looks like a ripped piece of paper

The button to turn compatibility mode on or off is located in the browser bar, right next to where you enter urls. It is there all the time in versions 8 and 9, independent of whatever website you might be viewing. Here is a picture of what it looks like :) What version of Internet Explorer are you using? --Dianna (talk) 02:47, 12 November 2011 (UTC)

In IE9, it is Tools → Compatibility view and uses the same icon. {{Spaceflight lists and timelines}} looks fine in standard mode, with no wrapping; in compatibility view, the template itself does not resize when the browser width is changed, although the documentation does resize. ---— Gadget850 (Ed) ^talk 03:18, 12 November 2011 (UTC)

"until the IE problems are resolved"- I think you need to address your comments in that regard at Microsoft. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 16:06, 12 November 2011 (UTC)

Wide boxes

An editor comment to me that he's seeing {{campaign}}-boxes widen when [show]n, when in IE's do-it-wrong-mode (my term). Seems to me that their old-school mode might be getting the recent white-space: nowrap; tweak inadvertently applied to the ul/ol elements. If so, something like:

.hlist ol,
.hlist ul
{
 margin: 0 !important;
 white-space: normal; // for old-ie-modes?
}

might help. Might help to use !important, too. Alarbus (talk) 05:01, 12 November 2011 (UTC)

Unfortunately, that does not help. IE still overrides it with nowrap for the list items. — Edokter (talk) — 09:34, 12 November 2011 (UTC)

The items are what we want not-wrapping. A few people are reporting extreme widening and I'm thinking that somehow means IE is wrongly applying the nowrap to the UL the LIs are contained in. Do you know what element is forcing things wide? Hit it with a rock specific rule. It could be another layer up; doesn't navbox fill the list-table-cell with a div&&padding? It could be that. One fellow said two-screens-wide, which would mean the nowrap was applied to a long list of items, putting them all on one line. That points at nowrap being applied to the UL or something further up. Alarbus (talk) 10:06, 12 November 2011 (UTC)

This is the rule as it currently is:

.navbox .hlist li {
    white-space: nowrap;
}

As you can see, only LI is targeted. It is only IE's uncompatibility mode (my name) that refuses to adhere to it. There is nothing upstream that would cause the entire list to not wrap. I could remove the line, which means going back to using the inline dot/nowrap templates, which do not play well with lists. — Edokter (talk) — 15:06, 12 November 2011 (UTC)

I'd read the css; it's not targeting the ul/ol, but who knows what a buggy browser might do. The {dot} templates and {nowrap} are horrid in many ways; accessibility, but also their huge preprocessing costs.

Seen the thread below about Night w reverting a lot of templates? Alarbus (talk) 15:13, 12 November 2011 (UTC)

Here's a screenshot if it helps. Nightw 16:05, 12 November 2011 (UTC)

Ouch; that's enough to make most people toggle the 'broken page' toolbar icon. Alarbus (talk) 16:22, 12 November 2011 (UTC)

Flatlist and browsers

Could I request that when editors and readers come forward with complaints about flatlist, that certain editors stop telling them to change their internet browser or switch to compatibility mode? This is the least helpful response possible, and is incredibly patronising - trying to switch the blame for the fault to the reader is not really fair. Whatever people's opinions of IE, it is the most widely used browser in the world, and the solution should be to make it work with IE. Number 57 11:29, 12 November 2011 (UTC)

Fact is, IE is the least capable browser. The problem is its deficiencies. It works as long as you don't use the "compatibility mode". Alarbus (talk) 11:43, 12 November 2011 (UTC)

IE is the leading browser used by our readers at 34%. Firefox is a close second at 23%. Wikimedia Traffic Analysis Report - Browsers ---— Gadget850 (Ed) ^talk 11:49, 12 November 2011 (UTC)

That sounds about right. Doesn't make it a good browser. It's not too much to ask that IE users use its standards mode. Alarbus (talk) (using Chrome) 11:55, 12 November 2011 (UTC)

Why should readers be asked to do anything? They should be presented with something that works. Number 57 12:42, 12 November 2011 (UTC)

Yes, they should be presented with the best work Wikipedia can present; HTML5, CSS3, JQuery. We should force their deficient browser into standards mode. I've made suggestions on how to fix this. Alarbus (talk) (using Chrome (15.0.874.120) 13:14, 12 November 2011 (UTC)

p.s. I use all the modern browsers. Alarbus (talk) 13:14, 12 November 2011 (UTC)

Could I ask that you don't use buggy software as an excuse for presenting our readers with sub-optimal markup? And while we're at it why is your sig full of deprecated markup? Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 16:01, 12 November 2011 (UTC)

Whatever one's opinion of IE is, the fact remains that it is widely used by readers—whether it's 34% or 10%, that's alot of readers. While you're busy telling everyone that comes here what the problem is and where the button is to fix it, please realise that for everyone that comes here there are probably a hundred casual readers out there that will not know what's causing the problem. No, readers should not be asked to do anything, but that's not the main issue here. It might be if readers were being made aware of what was causing the problem, but most of them will never know and the problem will remain. Until an appropriate discussion is had over the affects of this change and an adequate consensus is achieved, I'm reverting the changes on the templates that I watchlist. Nightw 13:15, 12 November 2011 (UTC)

Looks like you're being very disruptive, to me. There's a lot of talk about on this. Alarbus (talk) 13:26, 12 November 2011 (UTC)

But no consensus. As is quite obvious from the numerous complaints in the last two days alone, these changes are having an immediate affect on accessibility throughout the project. Nightw 13:42, 12 November 2011 (UTC)

Someone will revert you soon enough; this one may even be vandalism. Alarbus (talk) 13:47, 12 November 2011 (UTC)

Not that I normally take accusations of vandalism from newly-registered users seriously, but I'm not the one whose talk page is full of cluebot reports. Nightw 05:52, 13 November 2011 (UTC)

Thanks for reminding me to review that one, again. The single CluelessBot report is for this. I reverted the bot, of course. Are you done being disruptive? Alarbus (talk) 06:27, 13 November 2011 (UTC)

• Wikipedia:Manual of Style/Accessibility#Horizontal lists
• Wikipedia:Manual of Style/Military history#Campaignboxes

Alarbus (talk) 14:03, 12 November 2011 (UTC)

You appear to have a different understanding of "accessibility" to that used by most other people. {{Flatlist}} and .hlist improve accessibility. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 16:01, 12 November 2011 (UTC)

This is not a matter about consensus; this is about using available markup language. To be clear: There is nothing inherently wrong with Internet Explorer. All the markup being used here is compatible with IE8 and up. The .hlist class is working on IE right out of the box. It is IE's compatibility mode that is faulty. And that is not only the case with .hlist, but a lot of other stuff. I strive for maximum compatibility with all browsers; that included IE. However, if users decide, for whatever reason, to enable compatibility mode, which is not in any way necessary for Wikipedia, then it is justified to ask those people to disable it. We can account for practically every browsers out there, but not for every quircks mode that Microsft decides to throw at as; that is practically a black box we cannot cater to. Wikipedia is a standards-complient site, and it should be viewed with a standards-complient browser. That includes IE8, in standards mode. "Compatibility mode" is not the same as "compatible with everything", it actualy means "compatible with our own, old, obsolete and buggy browsers". Sadly, too many people make that mistake. — Edokter (talk) — 15:20, 12 November 2011 (UTC)

"...then it is justified to ask those people to disable it" → But how are you going to ask them? As you've seen, it's had an immediate response from editors just from the ones that you've already converted. Obviously there's going to be a whole lot of casual readers out there seeing the same problem and they won't have any idea how to fix it. I appreciate you and Joy showing us what's causing the problem, but there are obviously going to be a lot of readers out there who won't get that service. So this becomes an accessibility issue. And, other than readers using a screen reader no longer hearing "dot" after each link, I'm not seeing how it's an improvement over the previous markup. That's clearly something the community should determine. Nightw 15:54, 12 November 2011 (UTC)

"other than readers using a screen reader no longer hearing "dot" after each link, I'm not seeing how it's an improvement" - but apart from that, what have the Romans ever done for us..? Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 16:01, 12 November 2011 (UTC)

I'm in the process of creating a hack that will force IE6&7 into submission. That means disables the no-wrap, which is not a vital point anyway. — Edokter (talk) — 16:05, 12 November 2011 (UTC)

Excellent, thank you. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 16:49, 12 November 2011 (UTC)

Maybe it's a big deal for some, Andy—I don't know. Graham said it wasn't a high priority, but some obviously might disagree with that. Either way, clearly we need to consider all our audiences and determine our priorities. Nightw 16:24, 12 November 2011 (UTC)

Well, I'd prioritise web standards, accessibility, semantic markup and improved performance, over pixel-perfect rendition in obsolete and buggy browsers. As someone just said on my talk page, users of such browsers still get the content, which is what Wikipedia is about. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 16:49, 12 November 2011 (UTC)

This discussion can be closed. A fairly (in hindsight) simple CSS hack took care of the wrapping issue, as well as the misalligned dots. Only downside is that individual horizontal list items in navboxes are no longer no-wrapped [in IE6 and 7]. — Edokter (talk) — 17:01, 12 November 2011 (UTC)

Looks good; the wrap is only gone for those other browsers, though. Alarbus (talk) 17:10, 12 November 2011 (UTC)

That's what I meant. — Edokter (talk) — 17:38, 12 November 2011 (UTC)

I am seeing a few missing dots in IE8, but no serious issues. I am going to re-install the new versions on the templates that Nightw reverted. --Dianna (talk) 17:50, 12 November 2011 (UTC)

Looks good Edokter; thanks for the hard work to figure it all out! --CapitalR (talk) 22:53, 12 November 2011 (UTC)

Looks perfect! Many thanks Edokter. Sorry if I made a scene... Nightw 05:22, 13 November 2011 (UTC)

hlist middot does not scale

I've no idea if this is the right place to ask this question, please advise if not.

The middot is implemented using , i.e. File:Middot.png. But, on my screen this picture is significantly uglier than  • , i.e. {{•}}, or  · , i.e. {{·}}, because a PNG is not a vector image that can scale to e.g. 18px. To reproduce in Firefox, press Ctrl + a few times.

Can this be fixed? Use SVG, or even simply the characters • or ·? --Joy [shallot] (talk) 10:59, 12 November 2011 (UTC)

It's an image, a: to get it out of the actual content, and b: because that's needed to position it; it's on the right-end of list items. The browsers I use all scale it up fine (including FF). I'd not be fussed over shifting to a slightly large base image. One of the main reasons for doing all this is to cut the huge preprocessing load all the {dot} template entail. Alarbus (talk) 11:09, 12 November 2011 (UTC)

To add, it's actually a background image which cannot be scaled, and background images not work with SVG images. And we can't use • because adding text requires CSS that is not compatible with older browsers. — Edokter (talk) — 18:12, 12 November 2011 (UTC)

Firefox has an option to "Zoom text only"; if that option is enabled, images (including Middot.png) don't scale with text. That strikes me as a significant problem with this particular hack. Powers ^T 03:47, 23 November 2011 (UTC)

Moot, as not using images anymore. Alarbus (talk) 03:52, 23 November 2011 (UTC)

Oh, so it was replaced after all? I see now that http://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=site&only=styles&skin=vector&* contains

   content: " ·";
   font-weight: bold;

Where exactly is the source for this, is it editable through mediawiki? --Joy [shallot] (talk) 12:50, 23 November 2011 (UTC)

It's in MediaWiki:Common.css. — Edokter (talk) — 13:11, 23 November 2011 (UTC)

Ah, so there it is. Earlier you said • wasn't usable... but · is? --Joy [shallot] (talk) 13:47, 23 November 2011 (UTC)

A • (bullet) is too big, a · (middot) is too small, but a bolded middot (·) is what has been used all along. I just hadn't figured out how to make it bold yet. — Edokter (talk) — 14:00, 23 November 2011 (UTC)

Space between brackets

So one of the hlist conversions I did was reverted because using the second level to replace brackets "appears to add extra spaces around brackets". Additionally, I've also noticed that the brackets can wrap separately from the items they're supposed to contain, which looks odd and potentially confusing. Is it possible to fix these issues? Reach Out to the Truth 04:15, 1 December 2011 (UTC)

Known issues. Unfortunately, they cannot be fixed. The space is actually considered a bonus to denote sub-lists. But the wrapping issue is due to limitations in CSS. — Edokter (talk) — 10:59, 1 December 2011 (UTC)

heading cells

The pseudo-headings "Genus" and "Species" in {{Storks}} are not marked up as heading cells. Is there away to do so, in {{Navbox}}? If not, is there a work-around? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:24, 6 December 2011 (UTC)

All navbox group cells are currently not headers; something that may have to be fixed. I was also thinking about having the option to put in native headers between the rows, just like {{infobox}} (e.g. header1= ... header20=), to avoid having to hack pseudo headers like this. — Edokter (talk) — 13:30, 6 December 2011 (UTC)

Not to derail your idea, which sounds fine, but that Doctor Who box could use an above on a subgroup. Alarbus (talk) 13:57, 6 December 2011 (UTC)

(edit conflict)(what-he-said) Hi. First off, none of the groups are being generated as th-elements, which is not good; should change. I just hlist'd storks and used a list in the title, too. This has caused a few anomalies. There's a span w/font-size: 110% in {title} that usually wraps everything, but the span is now being generated with a premature close after the first link rather than wrapping the while list structure; it's being generated within the first LI. I saw this earlier in Municipalities of Madeira; here it is wrapping the flag. Switching to a div might be an easy solution to this. I've also noticed that we're getting a line-height: 1.5em from the ambient list-styling when we might-well be better served by either specifying it locally or using inherit as was done with margins on {{plainlist}} (wasn't that where?).

The pseudo-header 'Species' is dodgy; you really think it should be a header as opposed to an ordinary cell with a single-item list? It could be cool to have a mechanism to specify this, although I expect it runs deep to implement. Alarbus (talk) 13:42, 6 December 2011 (UTC)

Not really sure myself if it's a good idea to have lists in the Navbox titles. Another option there could be to go with a • or · (• or ·). -- WOSlinker (talk) 14:38, 6 December 2011 (UTC)

(ec) The title span is indeed causing Tidy to mess things up (again, just as above and below did). I made the title a div in the sandbox. The line-height in hlist is there to prevent any rows in navbox from becoming to narrow. It is also tuned per skin. As for the Dcotor Who box, a subgroup is not the best solution either, as the header turns too light (and is not quite logical without a real group preceding it). — Edokter (talk) — 14:40, 6 December 2011 (UTC)

I though the line-height was from further up; I'll have to have another look. The div would make the 110% then wrap the whole UL structure, right? As for Doctor Who, maybe you want 'above' twice; it's not really at the same level as the whole box title. I liked not having any colour in there, just getting whatever from the main template. Alarbus (talk) 14:51, 6 December 2011 (UTC) (ec, again, I know it;)

(ec) It seems apt, to me; same rationale as elsewhere. The stork one especially; the others mostly involved flags. I did a batch in Peru where it was a link to Peru being given after a region or something. Previously is there was a pipe "|" being used. (I know "comma"). Anyway, with a few tweaks it should be able to work fine without the font and heigh issues I mentioned. I'll pause doing it. Alarbus (talk) 14:51, 6 December 2011 (UTC)

OK, in the sandbox, the group cells are now table headers and the title is now a div instead of a span. Please double-check if there is any breakage I missed, before I make it live. — Edokter (talk) — 16:18, 6 December 2011 (UTC)

I previewed and inspected stork and Madeira, and the div works; wraps the UL; sizes right. But I also did Doctor Who and another and am seeing an odd increase in the titlebar height; extra space along the bottom, about 4px. Not sure what this is, but I've seen off by 4px on the bottoms of divs before. In good browsers, too; Chrome and Firefox: same. I'm tired and have to call it for now. So I'd say go slow, the issues out there now are minor and will keep a day. I'll look again tomorrow. Oh, the TH was fine in all cases. Still wondering a bit about where the line-hight is coming from, but didn't look at that; did fuss with the idea that the div needed display:inline, but it didn't seem to matter. Thanks. Alarbus (talk) 16:55, 6 December 2011 (UTC)

I can't see any increase in titlebar height in either IE, Chrome or Firefox. — Edokter (talk) — 17:59, 6 December 2011 (UTC)

File:Navbox titlebar height issue screencap-alarbus-chrome.png

This is what I'm seeing, now; that was captured in Chrome, but Firefox looked pretty much the same. The difference is 2px; I have may have been zoomed before. It now has the 110% span wrapping all LI in {Storks}, which I don't recall seeing. There are multiple spans in there now. On {Madeira} the span is only on the flag's LI. Other things I'm noticing are the [collapse], which is nice. I'm also seeing the sublist-generated closing ")" as bolder than its mate, so maybe a rule needs a tweak. Alarbus (talk) 02:52, 7 December 2011 (UTC)

You do have a sharp eye; I did see a one pixel difference when zoomed. This was due to the padding in hlist, not the header font size. I disabled the padding in headers; it is only applied in data (list) cells now. — Edokter (talk) — 11:41, 7 December 2011 (UTC)

Thank you. I'll clear everything and have a look around. I'm going to del-tag that image as I'm not sure it's a valid license. Will report back anything I find tomorrow. Alarbus (talk) 13:13, 7 December 2011 (UTC)

one more thing; the new group-THs should have a scope="row" attribute and the others scope="col". Alarbus (talk) 17:24, 6 December 2011 (UTC)

In the Stork example, the "Genus" cell should have scope="col" (not "row"); as should any cell in a row of headings. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:20, 6 December 2011 (UTC)

Not possible within the scope of navbox. That simply falls outside its design specs. — Edokter (talk) — 23:36, 6 December 2011 (UTC)

the example I provided above shows it's being used in this way; I doubt it's the only such occurrence. How do you propose that we resolve this? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:38, 7 December 2011 (UTC)

Navbox does not posess the concept of column headers, only row headers. Perhaps {{navbox with columns}} provides a better platform if column headers are really needed. — Edokter (talk) — 23:08, 7 December 2011 (UTC)

considering that navbox with columns is a frontend to navbox, that would require a serious rewrite. Frietjes (talk) 23:13, 7 December 2011 (UTC)

Navbox-with-columns uses navbox merely as a wrapper. The template only uses list1 and builds a table inside it that contains all the column logic. — Edokter (talk) — 23:24, 7 December 2011 (UTC)

Whoever did that in {storks} deviated from proper use of {navbox}. The solution is to not do that. They did so visually, not by following the design. Forgive them for they know not what they do. Alarbus (talk) 06:46, 8 December 2011 (UTC)

Again: this is probably not the only example. How would you achieve the obviously-desired, an not unreasonable, outcome? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:35, 8 December 2011 (UTC)

While one might be able to do something more meaningful by nesting the {navbox with columns} in a {navbox} with some child/subgroups or... something more, what they really need is a {{Taxonavbox}} of their very own. Better they rethink their approach and do something that works for them and also fits the tools at hand.

We've got other issues to work through, like the habit people have of sticking loose plaintext labels into navbox list items. Alarbus (talk) 03:59, 9 December 2011 (UTC)

I doubt that this is specific to taxonomic articles; it could be motorcar manufacturers and their models; football team managers and trophies won, or many other such sets. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:13, 9 December 2011 (UTC)

Not really; groups per se apply to the lists that go with them (i.e. are row headers); it's just that this box has more relationships between elements than navbox has in mind. You could probably explicitly specify the scope as col; would have to be 'last' re the embedded one. Alarbus (talk) 02:52, 7 December 2011 (UTC)

Thank you for your quick work on this. Pressure of time means I may not be able to participate in further discussion and testing until the weekend. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:20, 6 December 2011 (UTC)

Navbar/sandbox

Last edit should be undone (or corrected). Its include {{#if:{{{name|}}}|{{Navbar/sandbox|{{{name}}} which means a lot of page now includes Template:Navbar/sandbox. Christian75 (talk) 12:37, 7 December 2011 (UTC)

Fixed. — Edokter (talk) — 12:47, 7 December 2011 (UTC)

One dot too many

Not a huge issue, but horizontal lists (not sure if that is the cause) are rendering one dot too many. That is I see:

list-item · list-item · list-item · 

And the last one looks (and is) out of place. I have corrected it in a template but it got reversed for being deprecated. Fine by me, I am all for usability, but it would help avoid more of theses cases if the current version looked correct, which it does not. Using: Opera 10.10 - Nabla (talk) 16:50, 8 December 2011 (UTC)

I don't know what the current version of Opera is, but in other (modern) browsers, the last dot is removed using the :last-child selector, something Opera 10.10 may not understand. I'd like to know which version (if any) started supporting it, then I can fix it by having javascript remove the dot (as already happens in IE6/7). I've seen older versions of Safari lacking support as well, a webkit version would also help. — Edokter (talk) — 18:39, 8 December 2011 (UTC)

According to Quirksmode, Opera 10.10 should support :last-child. Can anyone confirm? — Edokter (talk) — 21:38, 8 December 2011 (UTC)

It would be interesting if Nabla tried the CSS3 Selectors Test and gave us the results. ---— Gadget850 (Ed) ^talk 16:48, 9 December 2011 (UTC)

And it looks like Chrome 10 has a bug here: [1] [2] ---— Gadget850 (Ed) ^talk 16:52, 9 December 2011 (UTC)

@Gadget850: Not sure if what asked for but: «From the 41 selectors 41 have passed, 0 are buggy and 0 are unsupported (Passed 574 out of 574 tests)» There is also a bunch of pages (or sections) about each selector. Most have a grey rectangle with a green stripe on the top. There is one at :last-child with two stripes, one being red; not sure if that is 'bad', but is in an example with:

div :last-child {
}

<div> 
   <div></div>
   How about regular text...
</div>

Opera 10.10 is a year or maybe two years old. It goes 11.60 or whatever currently. Do not bother much trying to fix it if it is corrected in recent versions (and don't even think in *telling* me to change to *firefox* - or I'll insult you :-) - or to update - that I will, one of these years :-) no need to rush - Nabla (talk) 22:59, 9 December 2011 (UTC)

Oh! It is a good thing making things look nice and working. Great. But it is also a good thing to keep it simple and not overloading both people and browsers with layers of fixes of fixes of fixes (repetition intentional) that cost resources. - Nabla (talk) 23:04, 9 December 2011 (UTC)

Your browser passes the test; one bar on the last-child: test page is supposed to be red. And my fixes are always from the ground up, not layered. Just a curious example, perhaps Opera 10.10 mixes up CSS priorities. But I'm not fixing this one... — Edokter (talk) — 23:11, 9 December 2011 (UTC)

Fine by me. Please don't take me wrong, but if the browser is OK, but the display is not, what is not OK then? Please, keep things simple. Being up-to-date with all of the latest is not necessarily good. And good work. - Nabla (talk) 11:37, 11 December 2011 (UTC)

Howto get even/odd row style in {{navbox with columns}}?

{{navbox with columns}} is used in {{CJK ideographs in Unicode}}. Is there an easy way to introduce even/odd line backgrounding? A regular navbox does so automatically (transparent/light grey). -DePiep (talk) 15:03, 9 December 2011 (UTC)

The only way I see how to do it easily is to nest a Navbox within a Navbox with columns. — Edokter (talk) — 15:10, 9 December 2011 (UTC)

Another hlist construct to consider

Some navboxes have this item of thing:

Which is the "best" way to do it. Version A or Version B? Or should they be re-written as Version C or Version D? I suppose sometimes it's going to depend on the situation -- WOSlinker (talk) 14:32, 10 December 2011 (UTC)

I would favor version D, as that is what groups are for. Or as an alternative, use defenition lists instead:

— Edokter (talk) — 15:02, 10 December 2011 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Any construct like:

* '''South:'''
* Car
* Bus

is incorrect, because "south:" is not a member of the list which includes "car" and "bus", but a descriptor of such items. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:34, 10 December 2011 (UTC)

I've see a lot of this and the solution does vary, and in some cases I've not been particularly please with any of the currently available mechanisms. I've mentioned this issue several time, most recently on Andy's page. The best option is often adding another level of groups, but I believe people have opted for this light-weight inline form to avoid that. Typically I've seen this used instead of a third or deeper level. They want an inline form and we don't have one for these situations. I believe some form of definition list is the right structure. I'd not considered 'C', above, and believe it can be done with DL, too, but have not yet tried it. It's a change of look, and people push-back over that. A lot. I have used the non-sublisted 'E' form, too; it works sometimes.

As I said somewhere earlier, I see navbox and such eventually becoming DL structures from the top down at some point. Mobile viewing will force a move away from the inherent column structure that goes with using tables (inappropriately). Alarbus (talk) 04:29, 11 December 2011 (UTC)

The structural issue at hand is not limited to navboxes. See British people, specifically the caption under the image in the infobox (it's {{tl|32 Britons). This is 32 names in four rows and they have little labels; 1st, 2nd... This practise of labelling rows with an inline prefix is very common and needs support. Structurally, the closet we've got in DT/DD but this forces bold and a "·". Nested lists force brackets. Making the label a discrete list-item can achieve the 'look' but is semantically poor as a label is not part of the list. Please consider this, and offer some ideas. Alarbus (talk) 12:34, 16 December 2011 (UTC)

What it comes down to is that hlist is just as limited as regular lists when it comes to list headings. What I can do is have a DT trailing a ":" instead of a dot. — Edokter (talk) — 12:47, 16 December 2011 (UTC)

I'd be game for trying that. See {{The Holocaust}} where I've just used DTs followed by nowiki'd ":" which are getting a "·" after them (this is under 'camps'). The explicit ":" would be cut of course. I believe this is the only place I've done this, and don't think switching to a generated colon would mess much up out there. Also, there's something odd in that ({{Sidebar with collapsible lists}} re class=nowraplinks; a few of the generated dots are wrapping... varies with font metrics. Alarbus (talk) 13:31, 16 December 2011 (UTC)

Thanks. That part's much improved. This sidebar is full of disparate cases; others we probably don't want inline. I do understand that this is a complex mess. I see it as a result of years of stuff being hauled off in all sorts of anyone-can-edit directions. Alarbus (talk) 01:23, 17 December 2011 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ That's OK visally, but te rendered HTML (values abbreviated for readability) is:

<code>
<dl>
<dt><a href="..." title="...">Nazi Germany</a></dt>
</dl>
<dl>
<dt><i>People</i></dt>
</dl>
<ul>
<li><a href="..." title="...">Major Perpetrators</a></li>
<li><a href="..." title="...">Adolf Hitler</a></li>
[...]
</ul>
</code>

and that's not so good. I think we should write the optimal HTML markup, then decide how best to render it in wiki-markup; not vice-versa. In this case, or example, "Nazi Germany" should probably be a header table-cell. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:04, 16 December 2011 (UTC)

I know that structure is not ideal, I've just been trying to move things forward using the tools at hand. I've never looked at a {{sidebar with collapsible lists}} before and am not sure if further template structure might be nested in there (or if that would be well received). The various collapsible lists in there contain many varied structures. Some of the DLs would be best rendered inline (such as Belgium et al. under "camps") while other ("Nazi Germany") might be better as centred blocks (or TH if there's a way). ANyway, I've updated it to use more ':'. Not ideal, but a step closer. Alarbus (talk) 01:23, 17 December 2011 (UTC)

I don't know much about the <dl> html tag and its children, but here's a proposal for how the HTML might ideally look.

<code>
<dl>
   <dt><a href="..." title="...">Nazi Germany</a></dt>
   <dd><ul>
      <li><dl>
         <dt><i>People</i></dt>
         <dd><ul>
            <li><a href="..." title="...">Major Perpetrators</a></li>
            <li><a href="..." title="...">Adolf Hitler</a></li>
            [...]
         </ul></dd>
      </dl></li>
      
      <li><dl>
         <dt><i>Organizations</i></dt>
         <dd><ul>
            <li><a href="..." title="...">Nazi Party</a></li>
            <li><a href="..." title="...">Schutzstaffel (SS)</a></li>
            [...]
         </ul></dd>
      </dl></li>
   </ul></dd>
</dl>
</code>

This particular example has lists being nested in each other (the "People" and "Organization" lists inside of the parent "Nazi Germany" list), which makes it slightly more complicated than typical uses cases. --CapitalR (talk) 18:33, 16 December 2011 (UTC)

You have the structure about right. Much of this is about proper nesting. Your above html should be generated from this:

Nazi Germany

• People
  • Major Perpetrators
  • Adolf Hitler
• Organizations
  • Nazi Party
  • Schutzstaffel (SS)

(ignoring the ':' initial colon-level for indenting this post)

It's a question of controlling how this wiki-text, producing your html, is rendered in the sidebar (or navbox...) to get looks pretty much along the lines of what people have been seeking for years. If we don't support most of what they want, they'll revert:

• Diff of Template:The Holocaust
• Diff of Template:The Holocaust

Do look further, as there's more in the other collapsible lists...

Alarbus (talk) 01:23, 17 December 2011 (UTC)

Who has altered the template in the last day or so?

Someone has reformatted the lefthand section headers, which were previously formatted as flush-right text within the first column of the navbox, as centered text. This obviously represents the personal preference of one editor (or perhaps a handful—I cannot locate any talk page discussion on point of the history of the edit to determine who is responsible). This alteration looks amazingly bad from the standpoint of good layout and design, and obviously affects thousands of navboxes and the work of hundreds of editors who were not consulted in making this random change to the template. Please restore the previous flush-right justification for the section headers. Thank you. Dirtlawyer1 (talk) 12:45, 12 December 2011 (UTC)

My bad. Will be fixed soon. — Edokter (talk) — 13:07, 12 December 2011 (UTC)

Alignment of groups

Over the past couple of days there has been a discussion on the alignment of groups on both my own talk page (User talk:Rangoon11#WP:Deviations) and that of WOSlinker (User talk:WOSlinker#WP:Deviations) that I can now understand is perhaps best conducted here. From what I can gather, there is no policy against right alignment of groups (and in fact Template:Navbox specifically refers to both center and right alignment:

"groupstyle* CSS styles to apply to the groupN cells. This option overrides any styles that are applied to the entire table. Examples: groupstyle = background:#nnnnnn; groupstyle = text-align:[left/center/right]; groupstyle = vertical-align:[top/middle/bottom];")

However I can recognise that there are some editors who feel that right alignment of groups is standard to such a degree that the Wikipedia:Manual of Style/Accessibility guideline applies and that therefore all non-right aligned templates should be changed.

I have nothing against consistency per se but do feel that if a single approach is going to be applied throughout that left alignment of groups would be better, as list content is almost always left-aligned and for the lists and groups to have the some alignment is both more logical and more visually attractive.

Do others have any thoughts on this?Rangoon11 (talk) 18:33, 22 December 2011 (UTC)

Here are some examples for reference:

I prefer the right-alignment, as the header cells are better associated with the content, especially in the case where there are both long and short header cells. The left alignment doesn't flow naturally and looks somewhat odd/ugly with the big gap. --CapitalR (talk) 20:51, 22 December 2011 (UTC)

Let's not forget templates with sub groups and longer headings.Rangoon11 (talk) 21:11, 22 December 2011 (UTC)

There might be a case for subgroups, but I agree with Capital on the case of simply groups. --Izno (talk) 21:30, 22 December 2011 (UTC)

I prefer the appearance of the right-aligned headers. I am also in favour of the templates being uniform project-wide, as this gives a more professional appearance befitting a world-class website. --Dianna (talk) 05:04, 23 December 2011 (UTC)

As I said on Rangoon's talk page, and I and others said on WOSlinker's talk, this is an unhelpful deviation from the templates normal behaviour and should be fixed. The off-colours on the subgroups are unwarranted/unhelpful, too. Off to fix more. Alarbus (talk) 10:35, 28 December 2011 (UTC)

Option to remove border, but keep same "level" used for colouring

Could we add an option to achieve the same format as 'border=child', but without the lighter colouring? It seems like this could be possible if there were an option to not add the 'subgroup' class when 'border=child'. I understand that this is usually a good idea, but see here for example, where Epipelagic was trying to override the lighter colours. The lighter colouring isn't usually that noticeable, but when the template is next to another one that isn't lighter, it is noticeable. When the subgroups are being used within 'navbox with collapsible groups', it's not always desirable to have this lighter colour. I also tried some other hacks for this particular case, like here, but I think we could make this much less of a hack. Thanks! Plastikspork _―Œ^(talk) 05:00, 31 January 2012 (UTC)

Why would any of this be a good idea? Navboxes should be implemented normally, not using the odd two part mechanism Epipelagic has created some dozens of. His mechanism breaks the v·d·e system and requires all usages of these navbox pairs to “know” which half they are listed in and pass a parameter indicating it. This is a fundamental failure to encapsulate the navbox implementation. Most of these template should be split and the various usages tweaked to simply invoke whichever template. Alarbus (talk) 09:23, 31 January 2012 (UTC)

So, Alarbus, it is: Example bad, Suggestion survives. Plastikpork does not point to the How, but to the What: optionally keep the higher level colors. There could be other ways to achieve that. -DePiep (talk) 09:44, 31 January 2012 (UTC)

Not following. What's good about having two navboxes paired up like this? {{Physical oceanography}} is the sort I'm mostly talking about. See any of the uses, such as Seabed, which invokes that with: {{physical oceanography|expanded=other}}, other being the second navbox in there. Alarbus (talk) 10:29, 31 January 2012 (UTC)

Plastikpork asked about changing the colors. He added an example, which used a construction to get the proposed effect (outcome). Even if you point out that the example is bad practice (one might agree), that does not kill the core question. In other words: Ppork did not propose to start using split templates. Invalidating such one route to a solution does not prevent finding a different solution. -DePiep (talk) 10:45, 31 January 2012 (UTC)

See the history of the Modelling template; Plastikspork reworked it from the form that's still in place in ones such as Physical oceanography. Next step is to save the halves in two places and connect them up in the client articles. That's pretty much what Edokter is saying. The real issue is that templates are too large and make the articles using them dependent on the internal construction of the templates, which is the encapsulation issue I linked. The best outcome here isn't to make the odd construct have the standard colours, but to remediate the odd construction. I've been through the category of templates these are in and thing there are less than a dozen. There may be more out there, of course… Alarbus (talk) 11:10, 31 January 2012 (UTC)

I am reacting solely to your "Why should ..." post, clearly. Edokter below does not address your technical issue at all, he has a different line of reasoning. Of course Ppork did not use a good solution: he was asking for it. -DePiep (talk) 11:16, 31 January 2012 (UTC)

Plastikspork called it a hack, and no one's going to much argue with that. You seem to be say that I can't ask "why bother". I can. This is a poor practise that should be phased out. You can't use the v·d·e links with templates in the form {{Physical oceanography}} is implemented, which is not good. The colour shading mechanism that's in place for the different levels of navboxes is there to indicate structure; it should not be subverted to allow odd structure to mimik correct structure. Alarbus (talk) 11:27, 31 January 2012 (UTC)

The hack was the example. Ppork just asked: can we get that into a regular one. And you keep repeating: bad example!, bad example! I am not writing here to support that hack, and I did not write so. This post by Ppork is not about the technical issues you mention. Only now you introduced indicated structure, which was not in your OP. -DePiep (talk) 13:30, 31 January 2012 (UTC)

The group colors are 'hard' coded in CSS. Adding such an option would mean having to override the CSS inline. As for {{Modelling ecosystems}}, they look like two separate navboxes, so they probably should be two separate navboxes. — Edokter (talk) — 10:30, 31 January 2012 (UTC)

Yup. Alarbus (talk) 11:10, 31 January 2012 (UTC)

There are non-trivial issues here. The current template system just does not deliver in a satisfactory manner when the content issues are complex. In content areas that are not particularly complex, as in Template:Salmon, the system works just fine (apart from the classic Ford restriction: you can have any colour so long as it's black – or in this case puke purple). But in areas where content issues are more complex, there can be serious difficulties trying to shoe horn the current system into something workable. Some prominent examples are the global warming template, as implemented here, and the sustainability template, implemented among a plethora of other templates here. What I would suggest is that these examples represent significantly worse attempts to present solutions to complex content issues than the modifications I have been attempting. But naturally this should be up for debate. I asked Arabus some time ago for assistance on this matter, but he ignores the issue and seems to be under the impression that it doesn't exist. The answer is not just to split the templates into their component parts, as has been suggested. If only it were that simple. To understand why, we would have to digress into the specific information topology in the areas concerned. But I don't see why that is necessary. The real issue is: can templates be implemented in a more comprehensive and flexible way so they can better meet the outcomes content editors seek when the content becomes very complex? --Epipelagic (talk) 12:04, 31 January 2012 (UTC)

Coulda fooled me.

The {{global warming}} and {{sustainability}} templates, while rather over-large, are properly built; they get the normal shading out-of-the-box and the v·d·e links work, which they don't in {{Physical oceanography}} and the others like it. If you can make a case that the pairs need to stay together, then at least use the implementation form in global warming and sustainability. Alarbus (talk) 12:56, 31 January 2012 (UTC)

Yuk Alarbus, you find it really hard to let anything go, don't you? Anyone who wants to can examine the very unpleasant background that led to those remarks. It's true the v·d·e links don't work in the non-standard way I have been using on a few templates. That's because they are not currently implemented to work that way. Please be collegial and constructive, or leave this issue alone. --Epipelagic (talk) 13:25, 31 January 2012 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ I've placed in the sandbox version an option to use |border=child2 which keeps the default colours but still removes the border. See link for details. Probably needs a better name than child2 though. -- WOSlinker (talk) 13:32, 31 January 2012 (UTC)

I've changed it to 'sibling', seems to be an appropriate name. — Edokter (talk) — 13:57, 31 January 2012 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ IMO the restraints of the current feature set are a benefit to the project. Hard cases make bad law, and the approach over the last few years of aiming to simplify individual navboxes rather than add features to the meta-template has significantly reduced the average complexity of our navboxes from the hand-hacking days. {{Sustainability}} should be regarded as pathological, and {{modelling ecosystems}} works perfectly well as two discrete navboxes. My default approach to sprawling navboxes which have too much content to easily manage these days is to dial back the coverage. I'd certainly oppose the specific change in question based on the specific use case in question. Chris Cunningham (user:thumperward) (talk) 13:40, 31 January 2012 (UTC)

Well in the case of {{modelling ecosystems}}, Chris, what title could possibly be used for the second template? You can't call it "Modelling ecosystems – Non-trophic components", because that is utterly misleading. Likewise, for {{physical oceanography}}, you can't call the second template "Physical oceanography – Not Waves and Currents". The only way those templates can work effectively is to keep them together, but only display this half or that half, as appropriate, to keep the bulk down. Which is what I have been doing. --Epipelagic (talk) 14:14, 31 January 2012 (UTC)

I think that as it stands, {{modelling ecosystems}} has too much data on display. What I would like is to be able to divide that template into say four parts, rather than two, but have only one part displaying at a time, always at the top. At the bottom would be an appropriately titled pair which opens the other three headers. This would gives a much cleaner and more targeted approach than the current implementation, as seen say in {{sustainability}}. --Epipelagic (talk) 14:31, 31 January 2012 (UTC)

When I said "discrete", I didn't mean "standalone": I see nothing wrong with the current implementation, which uses two contiguous navboxes. The collapsing code there is not as elegant as would be ideal, but it works well enough for what is (or should be) an edge case. But to be quite honest I think the entire template needs re-thought because it suffers from exactly the same scope problem which plagues our coverage of topics on sustainable development: we assume that readers need some big-picture overview of anything that could possibly connected to the page they're reading rather than just the most appropriate or similar articles. As a purely crazy thought, I'd take all of the existing rows and turn them into individual navboxes for horizontal navigation and all of the existing columns and turn them into a single navbox for vertical navigation. This would leave each article needing the same number of navboxes in total (two) but with an order of magnitude less tangentially-related topics to try to wade through. I've put up an absurdly-quick demonstration at {{Modelling ecosystems/sandbox}} to demonstrate. Chris Cunningham (user:thumperward) (talk) 14:44, 31 January 2012 (UTC)

In that absurd example, one should just use template:navbox with collapsible groups, which is far less complicated. Frietjes (talk) 15:55, 31 January 2012 (UTC)

I'm not sure if the point I was making was clear enough: my intention is that only two of the sandbox's templates (the first one, and exactly one of the rest) would be used in any article. It is a phenomenon specific to particular topic areas on Wikipedia that the navboxes are ludicrously over-reaching. There are two ways to deal with that: either come up with increasingly baroque hacks to stuff more and more links into a single template, or to reexamine what links are actually needed and redesign the templates to suit. Chris Cunningham (user:thumperward) (talk) 16:31, 31 January 2012 (UTC)

New scenario

Here is another scenario. consider Template:Portuguese infantes, which has more than 20 groups. to make this work, we have a wrapper parent template, and two children with 20 and 4 groups respectively. I think it is far better to add a 'sibling' option to this template (very easy), than to add support for 4 more groups. In fact, we deleted forks of this template (see Wikipedia:Templates_for_discussion/Log/2011_August_5#Template:Navbox_long) which allowed for groups. It seems like it would be very simple to just add a sibling option here, and effectively support more groups in these rare cases. Frietjes (talk) 15:49, 31 January 2012 (UTC)

The alternative would be to question why we have a family tree masquerading as a navbox in the first place, and whether there is a genuine use case which requires an editor on Balthasar Charles, Prince of Asturias to get to Ferdinand, Count of Flanders with one click. Chris Cunningham (user:thumperward) (talk) 16:35, 31 January 2012 (UTC)

Then Template:London churches. Frietjes (talk) 16:42, 31 January 2012 (UTC)

That horror should be hacked up into something like its new sandbox, and the per-borough navboxes that it is composed of used directly alongside it. As I say, some projects seem to be able to keep their navboxes sane, while others could do with a little persuasion. Chris Cunningham (user:thumperward) (talk) 16:51, 31 January 2012 (UTC)

I see no problem with it being used in project space. On the other hand, why do we have Template:Infobox timeline (now deleted)? It looks like a fork of infobox, with the sole purpose to get 200 fields. Frietjes (talk) 17:46, 31 January 2012 (UTC)

But it's not just used in projectspace: it's deployed in articles. Chris Cunningham (user:thumperward) (talk) 11:17, 1 February 2012 (UTC)

Proposal for a more responsive navigation system

Can I please restate the proposal I made above, as it seems to have got lost. I explained it badly.

As it stands, {{modelling ecosystems}}, which is currently split into two divisions, has too much data on display at any one time. What I would like is to be able to divide that template into rather more than two divisions, but have the content of only one division displayed at a time, always at the top. At the bottom would be a (closed) header, with an appropriate title such as "Additional related topics in ecosystems". If opened, this would display the (closed) headers for the other divisions. If you opened one of those additional divisions, the template would reconfigure to display in the same way as it did to begin with. (That is, the content of the selected division is now in open display at the top, while the header at the bottom has closed again, still with its original title "Additional related topics in ecosystems", although what constitutes the additional topics has now changed).

This might not be simple to implement, but, in the spirit of Macintosh software, would give a much simpler, cleaner and more targeted approach than what is available now in the {{sustainability}} and {{global warming}} templates. This approach would minimise what is actually on display at any one time to just two divisions, in alignment with what Thumperward suggested above, but would still allow the user to drill down in a straightforward and flexible way, into large and complex topic areas.

If this is still obscure, I can make some mockups. --Epipelagic (talk) 14:31, 31 January 2012 (UTC)

it sounds like this would be possible by nesting {{navbox|border=child}} inside of {{navbox with collapsible groups}}. is the only reason for not doing this that the group labels are "bumped down" a level (i.e., they become lighter in colour)? if so, we should just add the previously suggested {{navbox|border=sibling}} option. Frietjes (talk) 15:58, 1 February 2012 (UTC)

You're tackling the wrong problem. The template massively overreaches in its coverage, and you're trying to find an elegant way of hiding that. The problem is that adding features which allow template authors to elegantly hide masses of links simply encourages people to add an excessive amount of links to navboxes, which makes them useless for their primary purpose (quick navigation). I provided an embryonic possible solution to this in the section above, which would reduce the number of links on any given page by an order of magnitude while still preserving the most relevant navigational content. Chris Cunningham (user:thumperward) (talk) 16:16, 1 February 2012 (UTC)

I don't agree at all with that assessment, Chris. If the navigation templates were to be implemented the way you suggest, users would frequently be stopped in their tracks, unaware of or unable to reach the very articles they might want to explore. The navigation templates would unnecessarily frustrate users or leave them ignorant of what Wikipedia actually offers. The gutted templates would fail too often in the very tasks they are supposed to facilitate, which is to allow users to become aware of and navigate to related and relevant articles. On the other hand, I agree absolutely with your minimalist approach when it comes to the interface itself. The templates should avoid clutter and be intuitive; but they should also be responsive, able to deliver in some depth when that is what the user wants.

It seems Chris and I are polarised on this matter, but either way, this is a decision that should not be set in stone on this page, but needs to be discussed at some stage by the wider community. In the meantime, this page would be a good place to explore options. So here for discussion is a mock version of an alternative way of implementing {{physical oceanography}}. To see how it works, click on the different topic areas at the bottom of the template. This implementation would in no way compromise Chris's "primary purpose (quick navigation)", since the quick navigation options would present as the uppermost options. --Epipelagic (talk) 00:48, 2 February 2012 (UTC)

There is no way to make that work which does not result in a collossal template should the reader disable (or not have) JavaScript. Ensuring that pages are functional and preferably manageable without JavaScript is a basic consideration in Web page layout. The only long-term solution to that is to avoid over-using JavaScript to hide unnecessary content. Chris Cunningham (user:thumperward) (talk) 10:51, 2 February 2012 (UTC)

I think navboxes were first conceived to have a place to store groups of links relevant to the page or subject where they are placed. Cleaning out un-needed clutter is a good habit anywhere but, trimming down a navbox of links where do you start and what are the prerequisites. It seems this is the job of navboxes to "store links" and I believe Epipelagic has a good model of how this burden of navboxes can be addressed. Mlpearc (powwow) 01:58, 2 February 2012 (UTC)

The place to "store links" is the category system. Navbox templates are there to quickly navigate throughout domains. They work best when the number of links is relatively small and the subject matter is relatively well-defined. After they pass a certain size or scope they are simply less functional equivalents of the category pages. Chris Cunningham (user:thumperward) (talk) 10:51, 2 February 2012 (UTC)

Not just "quickly" navigating, Chris. They also could provide an overview of the domain. And a complete set of links, while the Category system does not (Cat uses subcats and only straight associations). As for the number of links in a navbox: by structuring the template (according to the domain) the number of links can be high while maintaining the navigation functions. -DePiep (talk) 12:16, 2 February 2012 (UTC)

It is possible to provide a degree of structure to the navigation, but that is not the purpose of navigation templates. A street signpost tells you the right way to get to your destination; it may provide some additional contextual or geographical information on top of that, but that is not its main purpose, and providing too much of that can impede its main functionality. The features that {{navbox}} provides are designed to be optimally used to create lists-o-links, with only a little additional dressing. This is not an oversight. Before scrambling to add new features it is very important to consider whether they enhance or detract from the primary purpose of the templates, which is rapid navigation. Chris Cunningham (user:thumperward) (talk) 12:25, 2 February 2012 (UTC)

While it is theoretically possible to do the dynamic sort of navbox proposed, we shouldn't for all the reasons you've outlined. These things are way over the top and should be chunked-out along some reasonable lines. Some of the very large navboxes out there have a huge transclusion burden that they impose on all their client pages (albeit somewhat less with the hlist class). On small pages, such navboxes can dwarf the actual content (in which case the transclusion burden isn't critical), but on large pages, it can push the page over the edge, especially when combined with sibling navboxes (ah, others, not Edokter's term). Large navboxes also deter editing by many editors, which is the expressed intent of omitting the v·d·e links. The new hlist does result in greater ease of updating, and this should be complimented by reining-in overly broad concept navboxes. Alarbus (talk) 12:44, 2 February 2012 (UTC)

Chris, can you please make your position concrete, and show specifically how you would implement what you consider a proper navigation system for say Wind wave and Kelp forest. Alarbus says we shouldn't use flexible navigation "for all the reasons [Chris] outlined". My problem is that I cannot make real sense out of your reasons Chris, and thinking in terms of street signposts is misleading. Chris says "there is no way to make that work", and Alarbus says "it is theoretically possible to do [that]". Do you mean in JavaScript or css Alarbus? Alarbus raises a valid issue about increased burden, but issues like that need to be balanced with the gains. You say Chris that your position "is not an oversight". Is there a Wikipedia essay which sets out appropriate background on this topic? I have a raft of issues I would like to raise here, but so far there doesn't seem to be a space where they can be heard. --Epipelagic (talk) 21:59, 2 February 2012 (UTC)

I didn't say "we shouldn't use flexible navigation". You made that up; spun it your way. It's a strawman argument. Same for your purported "gains". I didn't have a specific implementation mechanism in mind; there's more than one way to skin a cat, although skinning cats is often poorly received. See also: Clarke's Third Law. Alarbus (talk) 05:04, 4 February 2012 (UTC)

I already made a quick mockup at {{modelling ecosystems/sandbox}} which demonstrates the method I'd use. Take all of the left-hand labels and use them to create a new navbox for vertical navigation of the topic. Then split each row to its own navbox. I've now created {{physical oceanography/sandbox}} which contains what I'd replace {{physical oceanography}} with on the wind wave page. Chris Cunningham (user:thumperward) (talk) 10:14, 3 February 2012 (UTC)

That's the right direction. I just noticed {{Artiodactyla}} which is another that's way too large and poorly implemented. There must be thousands more with the same core issues. Alarbus (talk) 05:04, 4 February 2012 (UTC)

Let's look at the different approaches for wind wave, and call Chris's solution approach A and the proposed solution approach B. The first point is that both these approaches initially display almost identical information, so we agree on that. Approach A uses a separate template for topic areas and approach B puts them in a footer. The first major drawback of approach A occurs when you come to the "Other" associated topic areas. Pretty much all subject templates would have a valid group for "Other" associated articles. But approach A cannot handle this as a topic area, because it has nothing to link to. This is why Chris has red linked it as "More...", but in practice this topic area would have to be omitted.

Then there is the way the templates behave when you click on a topic area. If you click on, say, Landforms, approach A takes you to the article on landforms, whereas approach B displays the physical oceanography articles associated with landforms. Now if you are a user browsing through articles, it is quite likely at this stage that you have no idea whether you are interested in physical oceanography articles associated with landforms. Approach B straight away gives you a list of the associated articles, and the user can immediately see if something is likely to interest them. However, approach A takes the user to the article on landforms. There the user might peruse the article, only to find nothing much is in it about how landforms appear under the water. That is reasonable, since it is only in the context of oceanography that it becomes important to talk about underwater landforms. So the user might then scroll to the bottom to find again a template relevant to physical oceanography, only to find, alas, that there isn't one. The user been dropped into a dead end, and may be a little rattled now, and perhaps be inclined to drop their exploration of articles in physical oceanography, if they haven't already forgotten that that was what they were doing.

Although it appropriate to use "landforms" as a topic header in physical oceanography it is not appropriate to template landforms as a physical oceanography topic. This is not cherry picking a rare exception. This situation arises all the time when you template topics. Another topic header with this problem is plate tectonics. It is appropriate in the context of physical oceanography to use plate tectonics as a topic area, but it is not appropriate to template plate tectonic with physical oceanography. A user who clicks on plate tectonics using Chris's approach is dropped into a dead end.

The navigation experience of users occurs in details like this. It is what makes the difference between a seamless experience rapidly exploring and moving between relevant articles, and broken experiences punctuated with dead ends and frustration.

Then we come to computer resources. I'm assuming here that approach B requires JavaScript. So let's distinguish dynamic templates which require JavaScript and static templates which do not. Thus, approach A uses static templates and approach B uses dynamic templates. But approach B could be initially deployed as a static template. Thus, the wind wave article would have the proposed template deployed as a static template, functioning exactly as Chris's templates function. If the user clicks on an article in the main body of the template, there will be no need to invoke JavaScript, and the template will behave as it would on Chris's approach. But if the user clicks on a topic area at the bottom of the template, indicating a desire to make a wider exploration of topics in physical oceanography, then that is the point where JavaScript can potentially kick in. If JavaScript is not available on the client, then the template will behave exactly as it would in Chris's implementation. But if JavaScript is available, then there will a brief pause while the computer replaces the static template with the dynamic version. This approach minimizes any overheads in using approach B. JavaScript and the associated overhead of having to load in a much larger template is not evoked unless the user indicates they want the wider exploration options, and JavaScript is present. Otherwise, the template is functionally no different from Chris's template. JavaScript is free and seems standard on most systems in most countries these days. Perhaps that's not true of mobiles and in some countries, but the approach above should work there as well.

There may well be solid reasons why these proposals should be promptly shot down in flames. But if it might fly, then there are many other significant advantages and possibilities still to be discussed. --Epipelagic (talk) 08:55, 4 February 2012 (UTC)

tl;dr Alarbus (talk) 09:00, 4 February 2012 (UTC)

There's no way forward here Alarbus, unless you are willing to actually think about it. --Epipelagic (talk) 11:40, 4 February 2012 (UTC)

Not reading a 5kb wall-of-text does not equate to not having thought about this. I did read the bit at the ending threatening more tl;dr material, which is what WP:Zombies do. Alarbus (talk) 14:06, 4 February 2012 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ As a one-off I'm going to try to tackle that whole chunk of text, but I'm not going to make a habit of it.

1. "Other" is a grab-bag of random and only tangentially related topics. Are articles on oceanography really so short of links to ocean that we need one in here? Why are vehicles shoved in here rather than given their own category, and is someone looking up some random page on an aspect of oceanography really going to need a link to any of them if they're not related to the subject enough to be linked in-article? Not having a "miscellaneous" category (which is what this is) forces editors to think about, and justify, new links being added. This is a Good Thing.
2. You're taking a mockup created in five minutes and treating it as a final implementation. In practice, the top-level links should all be to physical oceanography topics. In the mockup, the top-level navbox simply uses the labels from the present navbox. As these were poorly thought out in the first place, it's unsurprising that they are less useful when someone actually examines where they're going (which probably hasn't actually happened before).
3. You're assuming rather too much of the JS we use. We don't have any clever Ajax which would let us dynamically load in new content when someone clicks a link. Instead, the JS simply hides most of the content and un-hides it when the right link is clicked. The result is that anyone who has JS disabled always sees all of the content. This is unlikely to be fixed in the short to medium term, if at all. As for JS's availability, there are plenty of reasons why someone wouldn't have JS enabled, ranging from NoScript to using a text-based browser for the blind. Clever uses of JS are not a deal-breaker, but nor are they a panacea.

Chris Cunningham (user:thumperward) (talk) 11:55, 4 February 2012 (UTC)

Thank you. That's the clarification I guess. So in complex content areas, Wikipedia's basic tools for navigation, circa 1960s, are and will remain basically unworkable. Good luck, Chris, you have a sisyphean task. --Epipelagic (talk) 12:59, 4 February 2012 (UTC)

I wouldn't describe it as "Sisyphean". When I first started working with navboxes way back in 2007, the whole domain of templatespace was a train wreck with little or no standardisation. The situation is vastly better now, and if anything we're having this conversation because the navbox ssytem is so easy to use and inviting that it is actually overused. it's important that we don't add so much complexity to it that we end up creating complicated, scary templates that nobody can work with, which is what we had four years ago. Chris Cunningham (user:thumperward) (talk) 13:52, 4 February 2012 (UTC)

I was referring to "complex content areas" only. I certainly wasn't meaning to minimise in any way the excellent work you do on the core navigation templates, Chris, and I couldn't agree more with you about avoiding "scary" templates. That was precisely why I came here, looking for flexibility without being scary. It becomes apparent if you work with complex content that the core templates do not have anything near optimal functionality. I have experienced a lot of frustration trying to find more responsive ways that avoid scary templates. But it just can't be done within the present framework. If and when it becomes possible to use dynamic templates, there will be a new dawn. In the meantime, your task will be Sisyphean, because that particular ball (complex content) will always roll back as you keep trying to push it up the wrong hill. --Epipelagic (talk) 19:28, 4 February 2012 (UTC)

Chris, thanks for taking the time to rebut. Alarbus (talk) 14:06, 4 February 2012 (UTC)

Ever play 1960s Spacewar! ??? Alarbus (talk) 14:06, 4 February 2012 (UTC)

imageleftclass

would it be possible to add some sort of imageleftclass, so that this can be achieved using "imageleftclass = navbox-group"? thank you. Frietjes (talk) 00:36, 10 February 2012 (UTC)

There's already an imageclass which applies to both images. -- WOSlinker (talk) 07:48, 10 February 2012 (UTC)

I think he/she may be asking for a second one for just the left image? It doesn't look like "imageclass = navbox-title" or "imageclass = navbox-abovebelow" will change the background colour. The default class, "navbox-image" that is there isn't in MediaWiki:common.css. Plastikspork _―Œ^(talk) 14:31, 10 February 2012 (UTC)

Okay, I think I figured out why imageclass wasn't working, it wasn't in {{navbox with collapsible groups}}, which I fixed here. This appears to resolve the original request, although I imagine there may be a case where you want the set the background colour for the left image, but not the right image? Plastikspork _―Œ^(talk) 14:46, 10 February 2012 (UTC)

thank you for fixing the {{navbox with collapsible groups}} template. having a second class statement could be useful, but I don't have a pressing need for it. I can always override the colour on the right by setting it to transparent. Frietjes (talk) 15:56, 10 February 2012 (UTC)