Jump to content

Template talk:Navbox/Archive 14

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 10←Archive 12Archive 13Archive 14Archive 15Archive 16→Archive 20

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)

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)

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 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)

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 is end tag for "table" which is not finished. ---— Gadget850 (Ed) talk 00:40, 26 August 2011 (UTC)
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:
---— Gadget850 (Ed) talk 11:05, 26 August 2011 (UTC)
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)

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)

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.
Template as displayed in Internet Explorer 8
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.
Template as displayed in Internet Explorer 9 with compatibility mode turned on
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)
"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)
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'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)

Hi. I have been referred here by User:Frietjes re: Template:Roy Harper which has recently become illegible on my browser (IE8). All other templates fit my screen fine, there are 4 here (Jimmy Page) that are perfect. So, can anyone fix this? I am at the limit of my abilities, creating the template was hard enough and if it wasn't broken, why fix it? Thanks. Stephenjh (talk) 09:03, 12 November 2011 (UTC)

You should see the thread below: #Wrapping issues. The issue is that you're using IE's "Compatibility Mode" instead of standard mode. Button on your toolbar→click it. Alarbus (talk) 09:16, 12 November 2011 (UTC)
I thank you. Stephenjh (talk) 09:24, 12 November 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:

http://wiki.riteme.site/w/index.php?title=Template:Elections_in_Austria-Hungary&oldid=457475149

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)

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 {{{1}}} 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 {{{1}}} 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.
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 Analytics - User Agent Breakdown by Browser ---— 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)
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/wiki.riteme.site/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)

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)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Template_talk:Navbox/Archive_14&oldid=1146279454"