Template talk:Div col/Archive 1

From WikiProjectMed
Jump to navigation Jump to search
Archive 1

Only works in Mozilla browsers

This template currently uses -moz-column-count, which is a CSS extension presumably supported only by Mozilla browsers. --Mrwojo 02:21, 17 September 2007 (UTC)

Is there any column method that works also on IE and other browsers? Scartol · Talk 17:07, 20 September 2007 (UTC)
Yep, Template:Multicol and Template:Col-begin are two ways to create multi-column layouts. You have to specify the column breaks manually with those templates, but they get the job done. --Mrwojo 03:01, 22 September 2007 (UTC)
Now also works for WebKit-based browsers. —Ms2ger (talk) 13:58, 2 February 2008 (UTC)

Additional "div column" properties

Can we get support for col-width and col-gap (as well as their appropriate -moz- and -webkit- alternatives) added to this template. It makes sense for a "div column" template to include all the proposed div-column properties. I'd suggest the parameters "width" and "gap" for obvious reasons. As column-width and column-count are mutually exclusive it will be necessary to check that only one is used when both are specified (as it is already included keeping column-count as dominant and default behaviour seems uncontroversial).

Here is my proposed modification wikified: (see below) 


<div style="{{#if:{{{cols|}}} | -moz-column-count:{{{cols}}}; -webkit-column-count:{{{cols}}}; column-count:{{{cols}}}; | {{#if:{{{width|}}} | -moz-column-width:{{{width}}}; -webkit-column-width:{{{width}}}; column-width:{{{width}}}; | -moz-column-count:2; -webkit-column-count:2; column-count:2; }}}} {{#if:{{{gap|}}} | -moz-column-gap:{{{gap}}}; -webkit-column-gap:{{{gap}}}; column-gap:{{{gap}}}; }} {{#ifeq:{{lc:{{{small|}}}}} | yes | font-size:80%; }}">

At some point in the future it may also be beneficial to add support for the column-rule property, but as far as I can tell, the -moz- and -webkit- extensions do not support this property yet and so it would have no functional benefit. – Ikara talk → 01:22, 18 July 2008 (UTC)

After further research I found that there is a -webkit-column-rule already, but not the -moz- equivalent. Someone with quick access to a Webkit-enabled browsed may want to test it out (sorry, not me, I'm Firefox through and through). If anyone is interested I also created a redirect from {{Div end}} to {{Div col end}} as the functionality of the latter is simply a </div> tag (so "div end" describes it more generally) and the former is more readable. – Ikara talk → 01:32, 18 July 2008 (UTC)
More research yeilded that in cases where col-width and col-count are specified, col-count gives an upper bound for the number of columns while col-width gives a lower bound for column width, so specifying both can be useful. Thus my modified proposed modification now reads...

<div style="{{#if:{{{cols|}}} | -moz-column-count:{{{cols}}}; -webkit-column-count:{{{cols}}}; column-count:{{{cols}}}; }} {{#if:{{{width|}}} | -moz-column-width:{{{width}}}; -webkit-column-width:{{{width}}}; column-width:{{{width}}}; | {{#if:{{{cols|}}} |  | -moz-column-count:2; -webkit-column-count:2; column-count:2; }}}} {{#if:{{{gap|}}} | -moz-column-gap:{{{gap}}}; -webkit-column-gap:{{{gap}}}; column-gap:{{{gap}}}; }} {{#ifeq:{{lc:{{{small|}}}}} | yes | font-size:80%; }}">
Sorry it took so long to get there. – Ikara talk → 01:53, 18 July 2008 (UTC)
I see neither a purpose or a consensus for this change. Cheers. --MZMcBride (talk) 18:51, 21 July 2008 (UTC)

Allow the use of {{{1}}} instead of needing to specify "cols"

Replace every instance of {{{cols|2}}} with {{{1|{{{cols|2}}}}}}. Chris Cunningham (not at work) - talk 11:14, 6 October 2008 (UTC)

Merge to {{div col}}

This template does exactly the same thing as {{div col}}, so I've added support for the colwidth parameter to {{div col/sandbox}}. To complete the merge, sync {{div col}} with {{div col/sandbox}}, redirect this template to {{div col}}, and redirect {{colend}} to {{div col end}}. Chris Cunningham (not at work) - talk 23:29, 2 September 2009 (UTC)

Trying to work out why you've added colwidth to the -column-count styles and not the -column-width styles. Are you sure the two templates do the same thing? — Martin (MSGJ · talk) 11:03, 3 September 2009 (UTC)
D'oh. I've now fixed this. The two templates do indeed have the same purpose; neither of them made full use of the CSS column features though. The merged template does both. Chris Cunningham (not at work) - talk 13:23, 3 September 2009 (UTC)
Test cases. Chris Cunningham (not at work) - talk 13:27, 3 September 2009 (UTC)
 Done, could you update the documentation please ? —TheDJ (talk • contribs) 12:38, 14 September 2009 (UTC)
Done. Cheers! Chris Cunningham (not at work) - talk 13:01, 14 September 2009 (UTC)

small command

Hi, the current 80% font size appears very small on small monitors such as netbooks. Would it be possible to change the small= so that the font displayed at 90% - similar to the {{reflist}} command. 78.32.143.113 (talk) 15:54, 26 November 2009 (UTC)

Please note that this only happens when small=yes is set. However, I do agree that it should be 90% instead of 80%. I have added an {{edit protected}} template to request this change. Gary King (talk) 03:36, 27 November 2009 (UTC)
Yeah, I agree. So  Done. Thanks, GDonato (talk) 15:55, 27 November 2009 (UTC)

Column padding

Can the template be changed so that the padding between columns can be expressed as a variable? When using it for columns of text which are not justified (in the typesetting sense) the columns are a little too close. -- Alan Liefting (talk) - 21:31, 15 April 2010 (UTC)

Where is this currently a problem? I haven't seen anyone asking for this in {{reflist}}, which is what this was derived from. Chris Cunningham (not at work) - talk 13:07, 16 April 2010 (UTC)
When I used this template on User:Alan Liefting with only a small amount of text it was not apparent that there was two columns. Readers would have mistakenly read one sentence across two columns rather than down a one column. -- Alan Liefting (talk) - 21:59, 17 April 2010 (UTC)
It looks fine to me. Please link to the problematic revision. Gary King (talk) 23:16, 17 April 2010 (UTC)
It was not a revision - it was an early preview I did of the page. -- Alan Liefting (talk) - 23:54, 17 April 2010 (UTC)
Okay. Please provide an example then (i.e. a test case). Gary King (talk) 23:58, 17 April 2010 (UTC)
Don't worry about it. It only happens in certain cases ie. when there is a lot of short words in a short block of text over two columns. -- Alan Liefting (talk) - 00:28, 18 April 2010 (UTC)

colwidth does not work

colwidth does not work at all in this template for some reason. Please compare the last two testcases at Template:Div col/testcases for examples. The code for the live and sandboxed versions are essentially the same; could someone please replace the template with this to see if that works? Gary King (talk) 03:27, 23 September 2009 (UTC)

That version was causing errors in pages for some reason because the spaces in it were not spaces, but nbsp or some other weird character. —TheDJ (talk • contribs) 14:50, 23 September 2009 (UTC)
The reason for this problem is that when column-count is specified, it takes precedence over columnwidth. Since in this template the default value is 2 (a specification that was broken in that particular sandbox version), 2 columns will be used. I'll fix it. —TheDJ (talk • contribs) 14:53, 23 September 2009 (UTC)
Why not just copy the code from here and use most of that? Whenever I use {{colbegin}}, the template I created, I only used colwidth since it was more flexible, and now even that doesn't work anymore. Gary King (talk) 20:29, 23 September 2009 (UTC)
Fixed. — RockMFR 22:41, 23 September 2009 (UTC)
Not fixed. colwidth=25% doesn't work. —Eekerz (t) 03:32, 22 April 2010 (UTC)
I don't believe it was ever supposed to work with percentages. If you want 25% columns, then simply make 4 columns. It's the exact same thing. Gary King (talk) 03:34, 22 April 2010 (UTC)

Broken?

We've lost columns made with this template all over wikipedia. Is it broken? ɳorɑfʈ Talk! 00:04, 11 May 2010 (UTC)

Looking at the documentation, it appears to still be working. Gary King (talk) 01:00, 11 May 2010 (UTC)
If you take a look at the Awards and Running Totals sections of Wikipedia:WikiProject Guild of Copy Editors/Backlog elimination drives/May 2010, you'll see the code, but only one column. This has affected a number of other pages as well. Not sure why. ɳorɑfʈ Talk! 03:11, 11 May 2010 (UTC)
Very bizarre, now appears fixed! ɳorɑfʈ Talk! 07:21, 11 May 2010 (UTC)

Padding on right hand side needed

Can we add <div style="margin-right:{{{2|20px}}};"> to give a 20px padding on the right hand side of the columns. If the template is used for columns of text there is only a one character spacing between the columns making the words in adjacent columns run together. -- Alan Liefting (talk) - 12:27, 17 July 2010 (UTC)

Where would this need to be inserted? Have you proved this works in a sandbox somewhere - this seems to be a very heavily used template, and as I'm not an expert on <div> syntax, I'm reluctant to change anything until I know it will work. —  Tivedshambo  (t/c) 07:07, 18 July 2010 (UTC)
Likewise. Could you test this to ensure that it works, then re-add the {{edit protected}} with a more specific request. Thanks, HJ Mitchell | Penny for your thoughts? 19:29, 18 July 2010 (UTC)
I found the code I pasted above on {{Multicol}}. I have given up using {{div col}} for my essays because of the lack of sufficient padding between columns. {{Multicol}} has a nice amount of padding between columns. The problem is quite apparent if there are two columns of text side by side. -- Alan Liefting (talk) - 02:42, 20 July 2010 (UTC)

Something borked...

As suddenly my nice evenly spaced columns on User:Ealdgyth are now all squished together... I see someone made some edits today... can we fix the issues please? Ealdgyth - Talk 14:32, 30 December 2010 (UTC)

Mine's gone funny too on User:Miyagawa. Miyagawa (talk) 21:40, 31 December 2010 (UTC)
Should be fixed now. — Edokter • Talk — 21:16, 1 January 2011 (UTC)

Support for column rules

I've added support for column rules in the sandbox; have a look at Template:Div col/testcases. Would there be support for adding this? — Edokter • Talk — 21:18, 1 January 2011 (UTC)

Tiny size

Could an option be added to specify 80% font-size with |tiny=yes in addition to the existing |small=yes? The new code is at Sandbox, testcases seem to work. In particular, I want to use it at {{Article alerts columns}} while avoiding duplicating the column div html/css. —  HELLKNOWZ  ▎TALK 14:41, 7 May 2011 (UTC)

80% is too small; 85% is regarded the minimum for use on Wikipedia. Anyway, a better option is to add an open {{{style}}} parameter in order to avoid having too many seperate paramters. — Edokter (talk) — 15:01, 7 May 2011 (UTC)
I see, I didn't know about 85%, Old method used 80% so I assumed it's OK. Anyway, sandbox and testcases for {{{style|}}}. —  HELLKNOWZ  ▎TALK 15:22, 7 May 2011 (UTC)
 Done. — Edokter (talk) — 16:39, 7 May 2011 (UTC)

Support for setting both width and count

Now that Firefox and Chrome have matching implementations for the case when both col-width and col-count are set, I updated the template to reflect this and allow setting the two properties at once. Since the detailed description of the changes was too big to fit the summary box, I'm posting them here:

  • Made css classes not mutually exclusive
  • (Re)Added unnamed {{{2}}} parameter for colwidth
  • Exchanged order of colwidth and colcount in code to make the {{{1}}} and {{{2}}} appear in the intuitive order
  • Moved unnamed parameters to inside the named ones, to make reading easier
  • Restore TheDJ's mutually exclusive defaults

--Waldir talk 02:11, 1 October 2011 (UTC)

The documented defaulting to 2 columns is no longer working as I expect. 174.119.19.211 (talk) 03:31, 1 October 2011 (UTC)
eraser Undone. While the newest versions may finally match in behaviour, there are still plenty of old version in use, so those broweser will exhibit broken behaviour. It is best to stick with what works. — Edokter (talk) — 08:37, 1 October 2011 (UTC)
Thanks, it's back to behaving as I expect. 174.119.19.211 (talk) 09:18, 1 October 2011 (UTC)

Bug in Google Chrome

Please see Talk:Lybia. A bug somewhere is causing the last line of text in columns to appear to the right, overlapping other content, when viewed in Google Chrome. --Stemonitis (talk) 18:30, 22 August 2011 (UTC)

That's a Chrome bug, not much we can do about it. Report it here. — Edokter (talk) — 19:02, 22 August 2011 (UTC)
Can we not find a workaround? --Stemonitis (talk) 19:04, 22 August 2011 (UTC)
I'm afraid not. The core column code is just CSS. Look at the resulting HTML source to see what the template produces. — Edokter (talk) — 19:06, 22 August 2011 (UTC)
In which case, can we implement something that detects the browser, and doesn't try to display columns to Google Chrome? At the moment, all Google Chrome users are getting mangled pages. --Stemonitis (talk) 19:12, 22 August 2011 (UTC)
The problem appears to be in how Chrome handles the column-width selector. If you use {{div col|2}} the problem does not occur in Chrome 13. ---— Gadget850 (Ed) talk 22:47, 23 August 2011 (UTC)
Appears to be resolved in Chrome 14. ---— Gadget850 (Ed) talk 23:15, 12 October 2011 (UTC)

Mismatched columns

I was looking at 1950 Southern 500#Finishing order and noticed it has a list of 75 items which it splits into three columns. But instead of the expected 25-25-25, it is showing up as 25-26-24. Mild Bill Hiccup (talk) 15:18, 22 March 2012 (UTC)

I see 25-25-25 on Firefox 11. ---— Gadget850 (Ed) talk 15:26, 22 March 2012 (UTC)
Interesting. I guess it must be a bug in Opera 11. Mild Bill Hiccup (talk) 18:12, 22 March 2012 (UTC)

I am seeing this at University of Oxford#Colleges. Firefox 18 breaks the columns 5-6-6-6-6-6-3, whereas Chrome 23 does what I'd expect and splits them 6-6-6-6-6-6-2. If I resize my Firefox window I can get other strange arrangements, 12-13-13 and below that 1-2-2-1. Also the list item "Regent's Park College" sometimes behaves very strangely, as if it was two list items. -- Fluteflute Talk Contributions 15:39, 31 December 2012 (UTC)

Extra vertical bar

Why is there a need for an extra vertical bar when setting the colwidth {{Div col||30em}}? Can it not be like this {{Reflist|30em}}? I want to add the {{Column-width}} parameter to {{Palmares start}} (sandbox). BaldBoris 14:15, 30 March 2013 (UTC)

'colwidth' is the second unnamed parameter, therefore you have to have a placeholder for the first unnamed parameter. If you use named parameters, then you don't have to worry about this. --— Gadget850 (Ed) talk 14:21, 30 March 2013 (UTC)
Why haven't you used named parameters for this template? BaldBoris 00:23, 31 March 2013 (UTC)
It does allow named parameters; use |colwidth=X instead of the double pipe. — Edokter (talk) — 00:41, 31 March 2013 (UTC)

Div col removal

This template is systematically being substituted by other column templates. Am I to conclude that there is no use for this template? That its use is no longer supported? -- P 1 9 9  ✉ 17:01, 12 May 2013 (UTC)

Replaced with what? Can you give a few examples? Other templates usually uses tables, which should not be used for building columns. — Edokter (talk) — 17:37, 12 May 2013 (UTC)
And on it goes for every town in the Philippines... -- P 1 9 9  ✉ 18:43, 12 May 2013 (UTC)
You will need to discuss that with the editor who made those changes. --  Gadget850 talk 21:29, 12 May 2013 (UTC)
(ec) My advice is to contact the editor in question (Frietjes) and ask him why he does that. Explain to him {{columns}} is using deprecated technology and that he should not use it to replace this one. — Edokter (talk) — 21:32, 12 May 2013 (UTC)
let me know when it works in the most common versions of Internet Explorer, and I will start using it in articles. last time I checked, IE 8 and 9 still had the majority of the IE market share. and you can feel free to use she/her when referring to me. Frietjes (talk) 14:48, 13 May 2013 (UTC)
Per Wikimedia Analytics - User Agent Breakdown by Browser IE7 1.7%; IE8 5.6%; IE9 7.56% . --  Gadget850 talk 21:49, 13 May 2013 (UTC)
IE10 is the current Microsoft browser, which supports columns. There is no need to remove existing uses of this template. Using tables is deprecated; it is detrimental to accessability. — Edokter (talk) — 22:11, 13 May 2013 (UTC)
I agree, which is why I replace tables used for columns with either {{columns}} or {{col-begin}}/{{col-break}} (see here). this will be easy to change once IE >= 10 is the more popular. what was never mentioned is that if you look back in the history before those diffs, each of those articles were using tables for columns, rather than a template which can be tracked and changed. Frietjes (talk) 23:23, 13 May 2013 (UTC)
I don't think you understand. Either of those templates uses tables to build the columns. That means that when you replace div col with those template, you are actually replacing actual columns with tables. — Edokter (talk) — 19:06, 14 May 2013 (UTC)
no, I understand perfectly. we use templates for a particular function, not for the implementation of a particular function. if you don't want {{columns}} and {{col-begin}}/{{col-break}} to use an HTML table, then you change that template to use div tags like, for example, {{multicol}}. as I said, this edit is a step in the correct direction. all you have to do is change {{col-begin}}/{{col-end}}/{{col-break}} from HTML tables to divs and your "problem" is solved. Frietjes (talk) 20:29, 14 May 2013 (UTC)
Divs are completely unsuitable for building columns; they need their widhts to be set explicitly. Multicol uses a table as well. We need to move towards using CSS columns, and div col is the only template that does so. Replacing any instance of this template with a table-based column template is going backwards and should be avoided. Do not replace this template with table-templates and please revert any replacements you already made. — Edokter (talk) — 11:25, 19 May 2013 (UTC)
if "divs are completely unsuitable for building columns" then why is this template called "div col"? we should template function, not implementation, which is why {{columns}} is an appropriate name and {{div col}} isn't. again, no need to change the articles, just fix the templates. Frietjes (talk) 17:30, 19 May 2013 (UTC)
Don't fret over template names. This template use a div container that breaks into multiple columns using CSS. What I meant is there is no way to build columns using multiple divs without the CSS. I can't convert the other templates, because they are structured differently and would break them under certain contitions. — Edokter (talk) — 18:10, 19 May 2013 (UTC)
the name of the template is important. if a user is looking for a template to generate columns, he/she will naturally find {{columns}}, not this template. if the others are so incredibly bad, you should nominate them for deletion and have a bot convert the ones that it can, and flag the ones that it can't for a human editor to convert. Frietjes (talk) 18:16, 19 May 2013 (UTC)
Point on the name— what would you be looking for? But Edokter is right—— this template does columns more properly than the others. Just because no one has made a big push to update the other templates has nothing to do with its functionality. --  Gadget850 talk 18:45, 19 May 2013 (UTC)
and I look forward to seeing all of the other templates at WP:TfD, so we can use a template name the expresses the function, and not the implementation. until then I will continue to convert hard-coded html tables used for columns to use one of the various equivalent columns templates, as I have been doing in edits like this. Frietjes (talk) 19:40, 19 May 2013 (UTC)
So, we aren't going to convince you and you are going to continue as you desire. --  Gadget850 talk 22:34, 19 May 2013 (UTC)
yes, I will continue to make edits edits like this until you tell me why replacing the table with a template is not a good idea. Frietjes (talk) 15:19, 20 May 2013 (UTC)
The OPs complaint was about replacing this template with table based templates; he even linked to some examples. What about that? — Edokter (talk) — 15:48, 20 May 2013 (UTC)
haven't done that in quite some time, and in fact, one of the complaints was about this edit, which seems off-topic. Frietjes (talk) 18:34, 20 May 2013 (UTC)

do not split?

Is there a switch to activate to indicate that an entry/all entries not be split across columns? -- 65.94.79.6 (talk) 06:01, 18 June 2013 (UTC)

No. There is no way (yet) to control how items are split in CSS. — Edokter (talk) — 20:12, 18 June 2013 (UTC)

{{col-begin}}

Why does Template:Colbegin redirect to Template:Div col instead of Template:Col-begin as expected? —sroc 💬 10:22, 1 December 2013 (UTC)

Because colbegin was merged to div-col; it used the same method (CSS columns), while col-begin uses tables to make columns. — Edokter (talk) — 10:49, 1 December 2013 (UTC)
Yet {{col-begin}} still exists? It's confusing having {{colbegin}} and {{col-begin}} both existing and working differently with different documentation. Does {{col-begin}} still work with {{col-break}} and {{col-end}}, for example? —sroc 💬 11:00, 1 December 2013 (UTC)
Yes, they are part of the same set. — Edokter (talk) — 12:41, 1 December 2013 (UTC)
But {{colbegin}} (redirects to {{div col}}) has different documentation from {{col-begin}}. They apparently work differently, as the documentation for {{colbegin}}/{{div col}} suggests that it is not supported by all browser versions and lacks the functionality (or at least does not document it) that {{col-begin}} has to manually break columns using {{col-break}}. Shouldn't {{colbegin}} redirect to {{col-begin}}, since this is more likely to be what the editor intended (i.e., a typo leaving out a hyphen) rather than {{div col}} (a substantially different name)? —sroc 💬 12:56, 1 December 2013 (UTC)
{{colbegin}} is deprecated and should not be used. Hence it no longer has any documentation. It was also created years after {{col-begin}}, so it made sense to redirect col-begin to div col, as it shared functionality. A bot should probably replace all occurences of colbegin/colend. — Edokter (talk) — 13:09, 1 December 2013 (UTC)

Keeping lines together

I just came across a case where there is a div col with items that looks something like this:

  • item 1
  • item 2

keep this line together

  • item 3

The problem is that the template is splitting the line "keep this line together" across columns, and it would be better if it kept the entire line of text in one column or the other. Is there any way to do that? Kendall-K1 (talk) 00:38, 14 October 2013 (UTC)

some discussion here, but as far as I know, there is no general fix. Frietjes (talk) 18:36, 14 October 2013 (UTC)
I know nothing about css and little about templates other than how to use them, so if this is a stupid idea, sorry. Would it make any sense to add a parameter to the template (keep=yes or similar) that would add the break-inside css property? Seems like it would be harmless in those browsers that don't support it, and would improve appearance in those that do. Kendall-K1 (talk) 15:09, 15 October 2013 (UTC)
no, it's not a stupid idea, it's a very good idea. it's just that there is no universal way to accomplish what you want. it seems as though adding 'break-inside: avoid-column' to the css would not break anything, and would potentially fix it in some browsers, but I have no idea how much this would help in general. Frietjes (talk) 15:56, 15 October 2013 (UTC)
Support is slowly gaining ground in browserland. I'll see about adding some CSS in Common.css. — Edokter (talk) — 17:32, 15 October 2013 (UTC)
CSS added. Good results in latest Chrome and Firefox. Opera (12.15) seemed to behave already, can't test IE10 and Opera 15 (which is basically webkit now). — Edokter (talk) — 18:43, 15 October 2013 (UTC)
If you have a test case, I can try IE10 and IE11. --  Gadget850 talk 12:38, 1 December 2013 (UTC)
See this article that was brought up on Template talk:Reflist. — Edokter (talk) — 12:45, 1 December 2013 (UTC)
IE10/11 looks good- no widows or orphans. --  Gadget850 talk 15:40, 1 December 2013 (UTC)

Mobile

On mobile you probably want to revert to one column layouts at all times. Is there anyway we could add a generic rule to Mobile.css for this purpose? Jdlrobson (talk) 02:29, 28 December 2013 (UTC)

Possible, but that is best discussed at Mediawiki talk:Common.css. — Edokter (talk) — 10:05, 28 December 2013 (UTC)

Huge amount of whitespace

At List of Christian denominations#Lutheranism, I am seeing a huge whitespace after the list in Chrome but not in Firefox. Is this a known issue? Is there any work around? --JFH (talk) 03:44, 27 May 2014 (UTC)

There is a bug in Chrome that miscalculates vertical space. The issue is amplified by the use of nested (**) lists. — Edokter (talk) — 08:25, 27 May 2014 (UTC)

Extra vertical space in first column

The first item in the first column seems to be bumped down by a half-line or so. Is this expected behavior or perhaps a Firefox bug (using Firefox 22.0)? ~ MD Otley (talk) 20:20, 3 August 2013 (UTC)

Example? It sounds like you may have a blank line before the first item, which triggers a paragraph break, causing the space. — Edokter (talk) — 10:19, 4 August 2013 (UTC)
I'm seeing the same thing in FF 17.0.7 (for Linux). I thought (as Edokter did) that it was due to a blank line, but removing that didn't change the appearance at all. See what you think: before and after my edit. For the record, when I position my "arrow" cursor just below the introductory text before the first list ("Twenty-three films…"), the arrow doesn't touch any of the text of first item of column 1 ["Doctor Zhivago (1965)"], but it does touch the tallest characters in the first item of column 2 ["Rebel Without a Cause (1955)"]. On my screen, this means that the first column is (AFAICT) 4 pixels lower than the second column. Since there's nothing in the generated HTML that would cause the columns to come out in different positions, it looks like this is either a Firefox bug or a problem with our CSS (which I don't have the patience to look through right now). - dcljr (talk) 22:20, 30 August 2013 (UTC)
I think I found the problem. A list (regardless of type) has a small top margin (0.3em). This margin manifests itself above the first list item. I'll reset this top margin when embedded in a div col. — Edokter (talk) — 00:24, 31 August 2013 (UTC)
Problem should be solved in a few minutes. — Edokter (talk) — 00:40, 31 August 2013 (UTC)
For the record, seems to be fixed now. Thanks. - dcljr (talk) 04:09, 7 December 2013 (UTC)

Thanks Edokter and dcljr for taking care of this, even though I didn't come back to follow up until now. Glad I can take this off my bloated watchlist now. :-) ~ MD Otley (talk) 18:34, 13 June 2014 (UTC)

Proposed edit

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

Any endorsements of / objections to the following, please..?:

Please replace the current version with this version in the sandbox. Functionally, it:

  1. Adds the (optional) parameter overallwidth ([1]) so that e.g. {{Start div col |overallwidth=50%}} may be used in place of {{Start div col |style=width:50%;}};
  2. Adds a closing </div> ([2]) to the template's noinclude section before the {{Documentation}}.

The code was then reorganized to make it easier to follow ([3]; cf, for instance, "style=" 's position) and some comment-notes included for the sake of future editing/editors. Sardanaphalus (talk) 19:20, 23 December 2014 (UTC)

oppose changes, since the diff is unreadable. Frietjes (talk) 19:24, 23 December 2014 (UTC)
  • That's a telling choice of diff, given the trouble taken and linked above: ([1]) ... ([2]) ... [3]. Sardanaphalus (talk) 22:20, 23 December 2014 (UTC)
Oppose. We need to talk about "code comprehensibility"... because your code is incomprehensible at best. You dump entire parser functions on one line, while the big plus of parser functions is being abled to be multi-line. A for the code...
  1. The closing </div> is redundant, as the opening <div> not transcluded to begin with. That actually creates an unbalance (which HTML Tidy will catch, but which we should not rely on anyway).
  2. The |overalwidth= (or |width=) parameter is redundant as well, as the template already support a |style= parameter, with which the width is set just as easily.
-- [[User:Edokter]] {{talk}} 20:11, 23 December 2014 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Code layout

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

Here's the code for the current version of the template:

Code
<includeonly><div class="div-col columns <!--
 -->{{#if: {{{colwidth|{{{2|}}}}}}
    | column-width
    | column-count column-count-{{{cols|{{#if:1|{{{1|2}}}}}}}} }}" style="<!--
 -->{{#if: {{{colwidth|{{{2|}}}}}}
    | {{column-width|{{{colwidth|{{#if:1|{{{2}}}}}}}}}}
    | {{column-count|{{{cols|{{#if:1|{{{1|2}}}}}}}}}} }} <!--
 -->{{#switch: {{{rules|}}}
    | = <!--empty-->
    | yes = {{column-rule}}
    | {{Column-rule|{{{rules}}}}} }} <!--
 -->{{#ifeq: {{{small|}}}|yes
    | font-size:90%; }} <!--
 -->{{#if: {{{style|}}}
    | {{{style}}} }}"><!--
 -->{{#if: {{{content|}}}
    |{{{content}}}</div>}}</includeonly><noinclude>
{{Documentation}}
</noinclude>

I suggest the four most significant features undermining its comprehensibility are:

  1. No presentation of the div's overall structural role;
  2. No apparent alignment/relationship between opening and closing braces across lines;
  3. {{#if:1...}} is cryptic unless it's already understood (ditto <!--empty-->);
  4. No apparent alignment/relationship between the div's class and style statements, nor presentation of their structural role.

Sardanaphalus (talk) 22:20, 23 December 2014 (UTC)

Don't confuse HTML with parser functions. Even though they are mixed, HTML is generally not prettyfied because it affects output when done wihtout comment markers, and too many comment markers negate the purpose of prettyfying, and you run the risk of introducing linebreask inside an element tag, which can be quite destructive. Only parser function need to be organized in order to analyze its logic. Your presentation obsfucated that logic. As for being cryptic... this isn't code school; we have help pages for that. Any template writer knows exactly what's going on, and HTML doesn't need explaining.
  • Don't forget that it isn't only programmers who edit and/or would like to edit and who should feel able to edit this and other Wikimedia/MediaWiki projects' templates. It isn't, therefore, only parser functions that need presentation – and describing attempts to do so as "prettifying" devalues, I believe, what should be a significant element in Wikipedia etc's future. Ditto the occasional constructs/syntax such as {{#if:true...}} and | =; I don't believe that every or even most things within code need their own explanations/annotations/etc, but, in the context of this and similar projects, working from bases such as "Any template writer knows exactly what's going on, and HTML doesn't need explaining" doesn't seem promising.
When and how to distribute syntax such as parser functions is one of those decisions for which I doubt there can be good, universal, hard-and-fast rules – and I happily admit that it's one of those decisions I can find myself revising. I suppose it's a decision as regards a balance between the immediate and more general context in which the syntax occurs that determines whether e.g. an {{#if:...}} seems best kept on one line, spread across two (often as "if... |then..." and "|else..."), three ("if...", "|then...", "|else...") or more. If, for example, the code proposed above had been endorsed but as (for example)...
Code
...this...
<includeonly><!--
  Notes: {{#if:true...}} removes whitespace from the parameter it surrounds;
         {{Column-width}}'s current default = 30.0em;
         "rule" = dividing line between columns.

 --><div class="div-col columns <!--
             -->{{#if:{{{colwidth|{{{2|}}}}}} |column-width
                 | column-count column-count-{{{cols|{{#if:true|{{{1|2}}}}}}}}
                }}"
         style="{{#if:{{{overallwidth|}}} |width:{{{overallwidth}}};}} <!--
             -->{{#if:{{{colwidth|{{{2|}}}}}} |{{Column-width|{{{colwidth|{{#if:true|{{{2}}}}}}}}}}
                 | {{Column-count|{{{cols|{{#if:true|{{{1|2}}}}}}}}}}
                }} <!--
             -->{{#switch:{{{rules|}}}
                 | = <!--(i.e. nothing if {{{rules}}} not set)-->
                 | yes = {{Column-rule}}
                 | {{Column-rule|{{{rules}}}}}
                }} <!--
             -->{{#ifeq:{{{small|}}}|yes |font-size:90%;}} <!--
             -->{{#if:{{{style|}}} |{{{style}}} }}"><!--
       -->{{#if:{{{content|}}} |{{{content}}}<!--
 --></div>}}</includeonly><noinclude><!--
 --></div>
{{Documentation}}
</noinclude>

...or... 

<includeonly><!--
  Notes: {{#if:true...}} removes whitespace from the parameter it surrounds;
         {{Column-width}}'s current default = 30.0em;
         "rule" = dividing line between columns.

 --><div class="div-col columns <!--
             -->{{#if:{{{colwidth|{{{2|}}}}}}
                 | column-width
                 | column-count column-count-{{{cols|{{#if:true|{{{1|2}}}}}}}}
                }}"
         style="{{#if:{{{overallwidth|}}} |width:{{{overallwidth}}};}} <!--
             -->{{#if:{{{colwidth|{{{2|}}}}}}
                 | {{Column-width|{{{colwidth|{{#if:true|{{{2}}}}}}}}}}
                 | {{Column-count|{{{cols|{{#if:true|{{{1|2}}}}}}}}}}
                }} <!--
             -->{{#switch:{{{rules|}}}
                 | = <!--(i.e. nothing if {{{rules}}} not set)-->
                 | yes = {{Column-rule}}
                 | {{Column-rule|{{{rules}}}}}
                }} <!--
             -->{{#ifeq:{{{small|}}}|yes |font-size:90%;}} <!--
             -->{{#if:{{{style|}}} |{{{style}}} }}"><!--
       -->{{#if:{{{content|}}} |{{{content}}}<!--
 --></div>}}</includeonly><noinclude><!--
 --></div>
{{Documentation}}
</noinclude>
...or, if whitespace were felt to be a significant issue, perhaps something like...
Code
<includeonly><!--
  {{#if:true...}} removes whitespace from the parameter it surrounds;
  {{Column-width}}'s current default = 30.0em;
  "rule" = dividing line between columns.

--><div class="div-col columns <!--
 -->{{#if:{{{colwidth|{{{2|}}}}}} |column-width
     | column-count column-count-{{{cols|{{#if:true|{{{1|2}}}}}}}}
    }}"
        style="{{#if:{{{overallwidth|}}} |width:{{{overallwidth}}};}} <!--
 -->{{#if:{{{colwidth|{{{2|}}}}}} |{{Column-width|{{{colwidth|{{#if:true|{{{2}}}}}}}}}}
     | {{Column-count|{{{cols|{{#if:true|{{{1|2}}}}}}}}}}
    }} <!--
 -->{{#switch:{{{rules|}}}
     | = <!--(i.e. nothing if {{{rules}}} not set)-->
     | yes = {{Column-rule}}
     | {{Column-rule|{{{rules}}}}}
    }} <!--
 -->{{#ifeq:{{{small|}}}|yes |font-size:90%;}} <!--
 -->{{#if:{{{style|}}} |{{{style}}} }}<!--
   -->"><!--
      -->{{#if:{{{content|}}} |{{{content}}}<!--
--></div>}}</includeonly><noinclude><!--
--></div>
{{Documentation}}
</noinclude>
...then the code is less compact and the "attribute-per-line" lost, but most alignments are retained and the larger structures remain more rather than less-readily discerned.
Sardanaphalus (talk) 11:46, 24 December 2014 (UTC)
There are as many styles as there are editors. The main point I'm trying to get across here is to not change the formatting en-masse in templates that are already organized (and most off them are), especially combined with other code changes, becuase it makes it very hard to compare the code (we have told you that repeatedly). It also has the appearance of you pushing your personal coding preferences. There is nothing wrong with the current layout; parser functions are organized so each condition is on a separate line. If you must orginize the HTML, do so in separate edits, but do not rearrange the parser functions. Especially, never remove linebreaks from them. It makes "human parsing" (analyzing code) very hard.
And yes, templates are written by programmers, wether you like it or not. There is no need to document every coding technique inline; it makes the code look "special" which it is not. That invites ohters to try and "normalize" the code instead of going to the help pages and learning why it is done that way. I understand if you discover a great technique and you want the world to know, but many template editors have been here for years and will removed these 'open doors'. -- [[User:Edokter]] {{talk}} 12:38, 24 December 2014 (UTC)
  • "The main point I'm trying to get across here is to not change the formatting [] in templates that are already organized..."
If this is the main point's basis, I think it's begging the point I'm trying to get across: that the way code such as the current {{Div col}} is organized is incomplete / insufficiently transparent / etc, especially given its context – that it's not and isn't, I believe, meant to be only "programmers" who write and/or contribute to templates. If code whose layout tries e.g. to maintain the visibility of higher-level structures alongside lower-level structures is code that disturbs "programmers", then I'd say there is something amiss.
I've decided not to say anything about the other statements and characterisations in the above as I suspect that would just distract attention from the point.
Hoping your Christmas was/is peaceful, Sardanaphalus (talk) 14:02, 27 December 2014 (UTC)
You are entitled to your opinion, but the code is fine as is. What may appear 'insufficiently transparent' to you, may appear perfectly transparent to others. Your formatting does not improve visibility; it may appear to improve the HTML, but is detrimental to the parser functions. Rule of thumb: HTML is linear, parser functions are not; your code reverses that principle. Parser code is programming language; treat it as such. -- [[User:Edokter]] {{talk}} 20:32, 27 December 2014 (UTC)
  • Do you think it's impossible / impractical / not worth retaining the visibility of higher-level structure within (horizontally-presented) HTML and (vertically-presented) parser-function code?
    For instance, with {{Div col}} to hand, how about:
Code
<includeonly><!--
 --><div class="div-col columns <!--
             -->{{#if: {{{colwidth|{{{2|}}}}}}
                 | column-width
                 | column-count column-count-{{{cols|{{#if:true|{{{1|2}}}}}}}}
                }}"
         style="{{#if: {{{colwidth|{{{2|}}}}}}
                 | {{Column-width|{{{colwidth|{{#if:true|{{{2}}}}}}}}}}
                 | {{Column-count|{{{cols|{{#if:true|{{{1|2}}}}}}}}}}
                }} <!--
             -->{{#switch: {{{rules|}}}
                 | = 
                 | yes = {{Column-rule}}
                 | {{Column-rule|{{{rules}}}}}
                }} <!--
             -->{{#ifeq: {{{small|}}} | yes
                 | font-size:90%;
                }} <!--
             -->{{#if: {{{style|}}}
                 | {{{style}}}
                }}"><!--
       -->{{#if: {{{content|}}}
           | {{{content}}}<!--
 --></div>}}<!--
--></includeonly><noinclude>
{{Documentation}}
</noinclude>
Sardanaphalus (talk) 01:00, 28 December 2014 (UTC)
I would like to point out that HTML-style comments <!--...--> should only be used outside of HTML tags, and certainly not within the value of a tag's attributes. Of the 8 HTML-style comments in the immediately-preceding code blob, there are 4 inside attribute values, and 4 are in valid positions.
But what existing problem are you trying to solve? Or is this just change for the sake of change? If you were creating a template from scratch, you can lay it out pretty much how you like, so long as the emitted wiki markup and HTML are both valid; but this is not the case here: it is a template created more than seven years ago, and with just 44 subsequent revisions. If there were a major problem with the markup, it would have been spotted and corrected; perhaps it has, so people do sometimes need to compare one revision with the next, and if they can't work out what was done, and there was no apparent problem with the previous version, they have a legit reason to ask "why?" --Redrose64 (talk) 15:09, 28 December 2014 (UTC)
  • "If you were creating a template from scratch, you can lay it out pretty much how you like, so long as the emitted wiki markup and HTML are both valid..."
If, though, the layout left drawbacks such as the four numbered earlier in this thread, you'd still soldier on with the less lucid version..?
Imagine someone is looking at the {{Div col}} code for the first time, or having not seen it for some time. Comparing the current with the alternate layouts above, you don't think it's likely to be easier for them to see that (i) the overall structure is a <div> (within an <includeonly>) that (ii) has two attributes and (iii) contains conditionals whose ends are more readily seen to correspond with their beginnings, because (i) the <div>'s tags are aligned and start/end on lines of their own; (ii) the starts of the class="... and style="... attributes are aligned (rather than the style="<!-- starting on the opposite side) and, thanks to the space above/below each, more visible; and (iii) the ends of the conditionals share the same alignment as their beginnings and then/else/etc actions..? Sardanaphalus (talk) 00:46, 2 January 2015 (UTC) @Redrose64: (in case it's now out of sight) Sardanaphalus (talk) 12:54, 4 January 2015 (UTC)
Redrose64, I can actually find no such restriction in the HTML5 recomendations. They are comment "delimiters", not "tags". While the syntax does inherently conflict when used inside a HTML tag, it is perfectly valid inside a (quoted) attribute value.
Sardanaphalus, I already spotted an error; the linebreak before the style attribute. Some browsers are know to choke on linebreaks within HTML tags. And since we can't use comment delimiters inside HTML tags (and outside attribute values), this construct is not going to work. -- [[User:Edokter]] {{talk}} 13:31, 4 January 2015 (UTC)
See 8.1.2.3 Attributes: "Attribute values are a mixture of text and character references ...". Therefore, when strings resembling HTML markup, including comments, occur inside quoted strings, they are taken as literals, and are not processed as HTML, and so a sequence formed of less-than, exclamation mark, pair of hyphen-minuses, etc. is not treated as if there was nothing there. --Redrose64 (talk) 13:53, 4 January 2015 (UTC)
So, they're not actually invalid, they're just not comments. In the context of MediaWiki however, they are stripped regardless. -- [[User:Edokter]] {{talk}} 14:09, 4 January 2015 (UTC)
  • Would the following be acceptable? To reduce the code's height,
  1. Each conditional's "then" output follows on the same line; if a "then" is the only output, this means it occupies no more than one line. If there is also an "else" output, this is placed (in alignment) on a newline, preceded by an "(else:)-->" to aid recognition;
  2. As they are relatively brief, the #switch's conditions have also been placed on a single line.
Code
<includeonly><!--
 --><div class="div-col columns {{#if:{{{colwidth|{{{2|}}}}}} |column-width <!--
                         else:-->| column-count column-count-{{{cols|{{#if:true|{{{1|2}}}}}}}}
                                }}" <!--
      -->style="{{#if:{{{colwidth|{{{2|}}}}}} |{{Column-width|{{{colwidth|{{#if:true|{{{2}}}}}}}}}}  [missing start-comment here]
         else:-->| {{Column-count|{{{cols|{{#if:true|{{{1|2}}}}}}}}}}
                }} <!--
             -->{{#switch:{{{rules|}}} |= |yes={{Column-rule}} |{{Column-rule|{{{rules}}}}} }} <!--
             -->{{#ifeq:{{{small|}}}|yes |font-size:90%;}} <!--
             -->{{#if:{{{style|}}} |{{{style}}} }}"><!--
       -->{{#if:{{{content|}}} |{{{content}}}<!--
 --></div>}}<!--
--></includeonly><noinclude>
{{Documentation}}
</noinclude>

Sardanaphalus (talk) 11:03, 6 January 2015 (UTC)

No, it wouldn't. Please sandbox the proposed changes, so that we can not only make a direct comparison with the existing code, but can also test it. Code blobs dropped into a talk page are not only untestable as they stand, they are also non-comparable. --Redrose64 (talk) 15:06, 6 January 2015 (UTC)
  • The above was meant as a continuation of gauging what's seen as acceptable code layout rather than an actual proposal for {{Div col}}. If, though, this code layout were to be deemed acceptable, I'd test it via the sandbox/testcases pages (and discover that it needed at least one correction, now noted above) before resetting the sandbox with the current template's code and leaving, for the sake of diff comparisons, a sequence of changes between that code and the (corrected version of the) above. Then I'd post a proposal. Sardanaphalus (talk) 09:09, 7 January 2015 (UTC)
  • @Redrose64: with the hope you weren't / won't be distracted by the abrupt action below. Sardanaphalus (talk) 05:37, 10 January 2015 (UTC)
If you can read and understand it, there is nothing wrong with the current layout. You proposals are not an improvement. If you have any functional proposals for the template, by all means post them. But I am going to close the discussion on layout. -- [[User:Edokter]] {{talk}} 09:47, 7 January 2015 (UTC)
  • Please do not continue to conflate this discussion with the request that opened it. To make this distinction clear, the original request (now closed) and this discussion now have separate threads.
Your attempt to impress a fait accompli also presumes that Redrose64 does not wish to respond to my previous post nor contribute otherwise. That is rude. If you no longer have any interest in the discussion, go elsewhere. Wikipedia is a communal effort. It is not your personal computing project. Please respect other people's involvement here. (Is this the kind of talk you do "get"?) At the very least, before you post your messages, imagine they've been written by someone else for you to read – I mean, really, actually imagine that their tone and attitude will be received by you. And, while doing so, please remember that something doesn't need to "be taken personally" for it to qualify as uncivil, lacking good faith, self-righteous or improper.
Is it going to be contempt, assertion, dismissal, ...?
Sardanaphalus (talk) 12:54, 7 January 2015 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Very strange behavior

I noticed today on this page or any that transclude it (example as "See Also" just below), that there is very strange behavior. When setting the browser (latest Chrome) to show this as two columns with four items each, then clicking on the last item in the first column ("List of cases of police brutality in the United States") the first item in the next column ("Encounter killings by police (India)") comes down to the bottom of the first column temporarily, until the clicked-to page loads. Why is this bug happening? ProtectorServant (talk) 00:07, 28 April 2015 (UTC)

That is strange. Most certainly a bug in Chrome, and there is not much we can do about it. I'll just put it away as a quirk. -- [[User:Edokter]] {{talk}} 01:02, 28 April 2015 (UTC)
See also

Just noting that it has been pointed out at Talk:Ketchup#Jumping_hyperlink.
 — Berean Hunter (talk) 03:30, 21 July 2015 (UTC)

I don't think that it's specific to {{div col}} - I've seen similar with multi-column {{reflist}}s in Firefox. --Redrose64 (talk) 07:37, 21 July 2015 (UTC)
I believe it is related to how the browsers handle the 30em parameter which never form multiple columns for me (using Firefox on Ubuntu). I prefer the old 2 col parameter which actually works. I agree that this probably isn't exclusive to this template.
 — Berean Hunter (talk) 13:06, 21 July 2015 (UTC)

30em not working?

Resolved

At The Martian (film), "30em" no longer appears to work in creating multiple columns of the "Production" section's crew list. I've temporarily changed the parameter to "2" but wanted to mention it here to put on others' radar. Erik (talk | contrib) (ping me) 14:48, 1 October 2015 (UTC)

You need to use {{Div col|colwidth=30em}} not {{Div col|30em}} --Redrose64 (talk) 15:15, 1 October 2015 (UTC)
Thanks! That worked. :) Erik (talk | contrib) (ping me) 15:23, 1 October 2015 (UTC)
You can also use {{Div col||30em}} (with an extra "pipe"). — Dsimic (talk | contribs) 15:44, 1 October 2015 (UTC)
Good to know! A fellow editor pointed that out as well. I went ahead with Redrose64's suggestion since it is more straightforward; the extra "pipe" isn't as clear of a parameter. Erik (talk | contrib) (ping me) 18:13, 1 October 2015 (UTC)
Div col parameters works slightly different from {{reflist}}. I do plan on making it support '30em' for the first parameter as well. -- [[User:Edokter]] {{talk}} 15:58, 1 October 2015 (UTC)
Look forward to it! Erik (talk | contrib) (ping me) 18:13, 1 October 2015 (UTC)

Specifying the maximum number of columns

Hello! I've read § Support for setting both width and count above, and I have a similar suggestion. How about making it possible to specify the maximum number of columns? With that parameter, it would be like "use the specified columns width, but don't split the content into more than x columns". That would be highly usable in "See also" sections with more than a few links, for example, in which a two-column compaction would be saving quite a lot of vertical space (which is premium on wide screens) in many articles, while it would prevent the not-so-pretty creation of, say, four short columns on large-resolution screens. Thoughts? — Dsimic (talk | contribs) 21:53, 2 March 2015 (UTC)

Specifying both count and width (in CSS) should result in count being used as the maximum number of columns. It may not work as expected in older browser that supported columns. I'll put it on my todo list. -- [[User:Edokter]] {{talk}} 07:57, 3 March 2015 (UTC)
Awesome, thank you very much! Thinking about the browser support, I'd say that it should be beneficial to implement new features even if they aren't fully supported in older browsers, of course if they don't break the rendering when interpreted by older browsers. By the way, a few hours after posting here, I saw an article containing a pretty large section with bulleted lists that would also really benefit from having this option available. — Dsimic (talk | contribs) 08:09, 3 March 2015 (UTC)
I've re-implemented this in the sandbox for testing, but still defaulting to 2 columns (for now). The only issue I came across is Opera 12 ignoring the count when both are used. -- [[User:Edokter]] {{talk}} 09:46, 19 April 2015 (UTC)
Sounds good, thank you! Hopefully it will soon hatch out of the sandbox. :) — Dsimic (talk | contribs) 10:00, 19 April 2015 (UTC)
Any updates on this, please? — Dsimic (talk | contribs) 10:18, 18 August 2015 (UTC)
Not happy with the code yet. -- [[User:Edokter]] {{talk}} 15:54, 18 August 2015 (UTC)
@Edokter: Any updates on this, please? — Dsimic (talk | contribs) 07:39, 7 October 2015 (UTC)
Sorry, new job takes too much time. Will get to it. -- [[User:Edokter]] {{talk}} 10:52, 7 October 2015 (UTC)

Gutter width

I was about to replace a template:multicol with a div col but couldn't because the multicol specifies a gutter width. That's apparently so the lists won't cause a "clear" after some infoboxes on the right side of the page. This is at German Type IX submarine. Could/should "div col" take a gutter width option? Is there a better way to do this? Kendall-K1 (talk) 20:09, 23 December 2015 (UTC)

Use something like {{div col}} --Redrose64 (talk) 13:55, 25 December 2015 (UTC)
That worked, thanks! I do think an explicit param, or documenting this usage, would help those of us who are not css experts and are trying to replace a multicol with gutter param. But I'll admit that's a pretty obscure use case. Kendall-K1 (talk) 14:45, 25 December 2015 (UTC)

colwidth not working properly?

See Cebu City. In Barangays, North and South should both be 24em. Why aren't they? Or at my wrong? Mary McAllen (talk) 09:28, 6 April 2016 (UTC)

They both have minimum width of 24em. But North has images from the section above to deal with, so there is less overall space for the colunms. -- [[User:Edokter]] {{talk}} 11:00, 6 April 2016 (UTC)
Surely the point of |colwidth= is to fit all columns to keep the width the same, but use fewer columns if necessary. Shouldn't minimum be not used? Mary McAllen (talk) 13:40, 6 April 2016 (UTC)
In fact the two multicol divs are not used in the same margins contexts: there are floatting element in the right, that may extend down to the first div bot not the second div.
To take into account the possible floating elements (the infobox from top of page, using 300px) and the two floatting images (using 250px), you need to set right margins for the divs so that they won't use that space reserved for floating elements.
If you set the same right margin on both divs, their usable content width will be the same, and columns will align. However you used a margin of 25% which is either insufficient (on narrow screens) or too wide (on wide screens): the correct minimum is 300px (the width of the infobox with its border and left margin).
Note that I could compact more the lists using a gap=0 (gaps between columns are not needed for bulleted lists, given that the list already includes a left margin, within which the bullet fits with a minimum indentation, so the bullets cannot touch the column on the left; the bullets and the indentation of items already provides a sufficient gap of separation between columns). Additionally the list items are never longer than 14em, you used 20em for the columns width). verdy_p (talk) 19:33, 31 May 2016 (UTC)

cols

Hi. Why was cols= marked as deprecated on the template's page? That's an essential function, and it is in no way mutually exclusive with colwidth=. The page says that the two are exclusive, but that's just false. Common sense says they are both complementary and essential. We don't always want everything formatted to unlimited, automatic, arbitrary numbers of columns. It wouldn't make any sense to have 10x2 layout instead of 2x10, for example. Screens will only continue getting bigger, but it still stands as common sense at any size. That's just a basic page layout concept. The "deprecated" marking needs to be removed. Furthermore, div col is generally the best all-purpose column formatting template, and it needs to ultimately subsume some other redundant and generally inferior ones, and I thank everyone who has contributed to it. — Smuckola(talk) 15:49, 6 October 2015 (UTC)

Hello! Please see the § Specifying the maximum number of columns discussion above; IMHO, having that kind of functionality would be very useful. — Dsimic (talk | contribs) 07:37, 7 October 2015 (UTC)

I agree that cols should be restored. Debresser (talk) 23:02, 12 July 2016 (UTC)

Strange column formatting

I added this template to Mishkei Herut Beitar and another article (I forget which) and I've noticed that the column lengths don't seem to be coming out properly. This one has six columns with 32 entries and I would expect it to distribute them 6-6-5-5-5-5. However, it actually distributes them 6-5-6-5-6-4. I wondered whether this may be because I was using 15em, but even if I increase if to 20, the distribution comes out as 7-6-7-6-6 as opposed to 7-7-6-6-6. Can anyone advise why this is happening as it doesn't look very good. Cheers, Number 57 10:50, 21 September 2016 (UTC)

On my screen it's 7-7-7-7-4. The layout is handled by your browser. The wiki code just emits css that specifies columns, but your browser places the columns based on how much screen space it thinks it has, and how much space each column takes up, depending on the the size of an "em" in the font you have selected. I agree that your layout is strange, as each entry in the column should have the same height. What browser are you using? Kendall-K1 (talk) 13:59, 21 September 2016 (UTC)
I've tried six different browsers. In five of them (Chrome 49, Firefox 48.0.2, Opera 12.17, Opera 36, Safari 5.1.7), there are 4 columns in Vector skin, 8-8-8-8. But if I switch to MonoBook skin, in Firefox I see 5 columns, 7-7-7-7-4. The sixth browser is Internet Explorer 8, where there is only one column, since it doesn't support columns. --Redrose64 (talk) 21:04, 21 September 2016 (UTC)
@Kendall-K1: I'm on the latest version of Chrome (53). Seeing the same results on two different computers too. Cheers, Number 57 21:56, 21 September 2016 (UTC)
I've come across this issue too. As an example, on the Mister Peabody article the list of episodes of Peabody's Improbable History is divided into 22em columns. At full screen 1920×1200 Firefox and IE11 display 5 columns in a 19-19-19-19-15 format but in Chrome 55 and Opera 42 it displays as 19-18-19-18-17, but perhaps more importantly the lines don't quite line up between the columns. (The difference is small – 1-2px – but it is there.) I also simulated 3840×2400, which gave columns of 9-9-9-9-9-9-9-9-9-9-1 in FF and 10-9-10-9-10-9-10-9-10-5 in Chrome.
I played around with it a bit in Chrome's inspector and found that disabling a margin-bottom: .1em which is applied to lis made the columns render as they do in Firefox (i.e. 19-19-19-19-15, with all the list items aligned properly). I'm not sure how this could be resolved, but it's a start.
P.S. The OS may also be relevant. My tests were done on Win 7.
Alphathon /'æɫ.fə.θɒn/ (talk) 18:25, 27 December 2016 (UTC)

Default setting

At present, using this template with no parameters, {{Div col}}, is equivalent to {{Div col |cols=2}}. It seems strange that the default should be a deprecated parameter, so I propose that the default ought to be equivalent to {{Div col |colwidth=30em}} (or 35em, or whatever) in a similar way to how {{reflist}} behaves. Any thoughts on why this wouldn't be an improvement? and what would be the best value for the default minimum column width? --RexxS (talk) 13:47, 23 August 2017 (UTC)

Oof, this template and its usage need some serious attention. Thanks for starting the conversation. In answer to your question, I suggest 30em, which appears to be the most reasonable match for cols=2 on most screens. Reflist uses 30em as the default if there are more than 10 items, so it makes sense (to me) to match that behavior.
I have added unknown parameter tracking to the template, which will populate Category:Pages using div col with unknown parameters.
I have also added Category:Pages using div col with deprecated parameters to track usage of |cols= and unnamed parameters. Both categories will take a few weeks to populate.
Fixing these will require careful thought, however, because if you simply remove the first unnamed parameter and there is a second one, the second one will become the first one and break the template's behavior in that page. We should probably convert all of the second unnamed parameters to |colwidth=, then convert any remaining unnamed parameters to an equivalent colwidth unless |colwidth= is already present. I don't know if I have that correct, though.
The parameter usage report shows the parameters that are in use and what their values are. There is a lot of garbage out there. – Jonesey95 (talk) 18:51, 12 January 2018 (UTC)
There are currently 43,000 unnamed first parameters (i.e. cols=), 19,000 unnamed second parameters (i.e. colwidth=), and 14,000 instances of |cols=. We're going to need consensus and then a bot. – Jonesey95 (talk) 19:25, 12 January 2018 (UTC)
This seems like a no-brainer, 30em is working great with {{reflist}}. Once executed, I'm happy to jump in with AWB to make a dent in the random parameters (as I did with reflist) while a bot is configure/approved.— TAnthonyTalk 21:34, 12 January 2018 (UTC)
TAnthony: Category:Pages using div col with unknown parameters is ready for a pass with AWB, converting the most common errors like "col width=" and "width=" to "colwidth=". It will continue to add articles over the next couple of weeks. You'll probably need to stay away from the deprecated parameters category, because conversions made to those articles will run afoul of AWB rule 4 against edits that do not change the rendered page. – Jonesey95 (talk) 16:40, 13 January 2018 (UTC)
There is a template, {{Draw key}}, which could be updated to reduce down the entires in Category:Pages using div col with deprecated parameters. -- WOSlinker (talk) 17:05, 13 January 2018 (UTC)
 Done. – Jonesey95 (talk) 05:15, 14 January 2018 (UTC)
I've cleared Category:Pages using div col with unknown parameters for now.— TAnthonyTalk 20:05, 14 January 2018 (UTC)

I had some changes prepared for this in the sandbox version of the template actually earlier in 2017, (Now cleaned up). I probably never deployed them because similar changes got held up at reflist or something. Also, i would like to note that while a fixed number of columns are bad, we do have some content that likely heavily makes this assumption and that might end up in unexpected ways if this is changed. Much more so than with references lists, which always had rather consistent looks. Make sure to test the content. If it's problematic, then maybe we should look at flexbox or something similar for this particular case, instead of column-width... —TheDJ (talk • contribs) 21:54, 12 January 2018 (UTC)

I've added some additional tracking at Category:Pages using div col without cols and colwidth parameters for when neither cols or colwidth are specified. -- WOSlinker (talk) 16:23, 13 January 2018 (UTC)
I'm curious about the purpose of this tracking. What problems do you expect it to help us identify? Should it be limited by namespace? I expect that most instances of div col with zero arguments will be fine when we migrate from 2 columns to 30em. – Jonesey95 (talk) 16:36, 13 January 2018 (UTC)
Yes, most will be fine for migration, just just think it will be useful to see the in a list to see if anything pops out as needing attention. -- WOSlinker (talk) 17:05, 13 January 2018 (UTC)
Has proved useful. Found Template:US highest, which was using {{columns-list}} to show a long list in two cols. Updated it to colwidth instead. -- WOSlinker (talk) 20:39, 13 January 2018 (UTC)
In looking at Category:Pages using div col with deprecated parameters, many are using a fixed number of columns; changing this to 30em with the proper parameter would indeed change the rendered page for many readers, so I would argue that the use of AWB is acceptable.— TAnthonyTalk 20:53, 14 January 2018 (UTC)
But would there be a need to edit many at all if the default in the template was changed from cols=2 to colwidth=30em and the cols parameter removed? -- WOSlinker (talk) 21:15, 14 January 2018 (UTC)
This report shows the usage of |1=, |2=, and |cols=. |cols=2 can simply be removed, since it is the default. |1=2 can also be removed unless there is a second unnamed parameter. |2= can be converted to |colwidth=. That would take care of at least 30,000 articles, maybe as many as 40,000 according to the report. We should create a separate discussion section below to figure out (or import from a previous discussion somewhere) how to convert each number of columns into an em value in order to roughly preserve the original editor's intent for each set of columns. – Jonesey95 (talk) 22:52, 14 January 2018 (UTC)

When converting {{reflist}}, I believe we kept any em widths, but removed fixed columns altogether, substituting 30em or nothing at all (since 30em is the default). The whole point of responsive column widths is that readers all have their own settings and screen sizes. Trying to "convert" 4 fixed columns to an equivalent width defeats this purpose.— TAnthonyTalk 05:28, 15 January 2018 (UTC)

I think that this template is a slightly different beast than {{reflist}}. Editors have laid out lists in columns that appeared suitable to their eyes, and if we convert a five-column list to a 30em list (two columns on most screens), I think editors will rebel. I would prefer to do something like convert cols=2 to 30em (or delete it and let 30em be the template's default), convert cols=3 to 22em, convert cols=4 to 18em, etc. (or something close to those values), and then let editors figure out how to proceed from there. The bottom subsection of this talk page section addresses how to do this conversion. – Jonesey95 (talk) 07:20, 15 January 2018 (UTC)

Transclusions in templates where converting from 2 columns to 30em won't work

There are a few templates that use divcol within a sidebar template, where 30em would not work, for example Template:Westernfilmlist. There are less than 50 of them though, so wouldn't take long to manually edit with suitable colwidth settings. -- WOSlinker (talk) 09:14, 13 January 2018 (UTC)

 Done. I took the liberty of making this its own section, because there may be more templates like this. I have gone through all of the templates linked immediately above and converted all of them to use |colwidth=, except in cases where the use of div col is in the documentation only. – Jonesey95 (talk) 15:40, 13 January 2018 (UTC)
I found at least one manually constructed sidebar while doing insource searches on Template space. There will be some strange stuff out there. – Jonesey95 (talk) 16:42, 13 January 2018 (UTC)
Here's some searches for template use with no params: colbegin, div col. Some are ok, and would still be fine with changed defaults, but some will need updating. -- WOSlinker (talk) 00:58, 14 January 2018 (UTC)
 Done. I have reviewed all of the templates linked immediately above and added |colwidth= to those that needed it. – Jonesey95 (talk) 05:10, 14 January 2018 (UTC)

Template:Palmares start

Can someone please take a look at Template:Palmares start? It invokes div col with a fixed number of columns as an unnamed parameter. I have attempted to work around it for the default two columns at Template:Palmares start/sandbox, but my logic isn't quite right. It should probably just be redirected to {{div col}}; it has a "source" parameter that is apparently not used on any pages, but other than that, it just takes an unnamed parameter for the number of columns, like div col does. – Jonesey95 (talk) 00:17, 15 January 2018 (UTC)

Nominated for redirect. See Wikipedia:Templates for discussion/Log/2018 January 15. – Jonesey95 (talk) 15:55, 15 January 2018 (UTC)

Possible early bot work

A bot could make a big dent in the deprecated parameter category by changing all of the pages listed in this insource search and this insource search to use |colwidth=. This is the fix. The 600+ templates listed in the results may need to be edited under manual supervision. – Jonesey95 (talk) 17:21, 13 January 2018 (UTC)

I have edited all of the affected templates. Pages in all other namespaces remain. – Jonesey95 (talk) 01:28, 15 January 2018 (UTC)

Conversion values: fixed column numbers to em values

How should we convert |cols=3, |cols=4, etc. to |colwidth=XXem? Is there a guide somewhere, or a standard practice? If not, let's make a proposal here and then discuss. – Jonesey95 (talk) 22:56, 14 January 2018 (UTC)

I tend to divide the col count into 60 when I convert these, but am not aware of a guideline. Kendall-K1 (talk) 01:27, 15 January 2018 (UTC)
I think that might be about right. Let's do some examples below. – Jonesey95 (talk) 07:20, 15 January 2018 (UTC)

Two-column list followed by 30em list

  • Two-col list
  • Two-col list
  • Two-col list
  • Two-col list
  • Two-col list
  • Two-col list
  • Two-col list
  • Two-col list
  • Two-col list
  • Two-col list
  • Two-col list
  • Two-col list
  • 30em list
  • 30em list
  • 30em list
  • 30em list
  • 30em list
  • 30em list
  • 30em list
  • 30em list
  • 30em list
  • 30em list
  • 30em list
  • 30em list

Three-column list followed by 22em list

  • 3-col list
  • 3-col list
  • 3-col list
  • 3-col list
  • 3-col list
  • 3-col list
  • 3-col list
  • 3-col list
  • 3-col list
  • 3-col list
  • 3-col list
  • 3-col list
  • 22em list
  • 22em list
  • 22em list
  • 22em list
  • 22em list
  • 22em list
  • 22em list
  • 22em list
  • 22em list
  • 22em list
  • 22em list
  • 22em list

Four-column list followed by 18em list

  • 4-col list
  • 4-col list
  • 4-col list
  • 4-col list
  • 4-col list
  • 4-col list
  • 4-col list
  • 4-col list
  • 4-col list
  • 4-col list
  • 4-col list
  • 4-col list
  • 18em list
  • 18em list
  • 18em list
  • 18em list
  • 18em list
  • 18em list
  • 18em list
  • 18em list
  • 18em list
  • 18em list
  • 18em list
  • 18em list

Comments on the above tests (feel free to add more)

On my screen, the above tests result in matching lists (2,3,4 columns; I have a relatively small screen). What do others see? I assume that if you are on mobile, you will see fewer columns in the "em" lists, and if you use a very wide screen, you will see more columns in the "em" lists. – Jonesey95 (talk) 07:20, 15 January 2018 (UTC)

On Firefox, with default zoom, monobook skin, window full size on 1080 width screen, I see 4,4,6. Changing to vector skin gives 3,4,6. -- WOSlinker (talk) 09:23, 15 January 2018 (UTC)
This will be primarily dependent on the available width between left sidebar and right edge. It will also depend on font face and size, zoom level, and various other factors. What works for you will not work for others, since there is no way that you can know how my system is set up. In short: you cannot establish a correspondence between column-count and column-width.
We have been over all this at reflist, let's not do it all over again. --Redrose64 🌹 (talk) 12:30, 15 January 2018 (UTC)
Exactly. I see 3,4,5 on my 15.4" Macbook Pro with Safari and the window at about 85%. It's 4,5,6 on my iMac. As I said above, trying to mimic the column layout exactly using em is futile and sort of defeats the purpose of dynamic columns. That said, I can foresee some pushback if we do not take this into consideration, as per your earlier example, if we changed 5 columns to 30em. I think it shows thoughfulness and good faith on our part to make an effort for the widths to be relative. Your suggestion that 2 columns change to 30em, 3 to 22em, and 4 to 18em seems as fine as any. It will not mimic the fixed columns exactly on every device but it will be an approximation less likely to invite objections.— TAnthonyTalk 15:03, 15 January 2018 (UTC)
Thanks for the help. As I said above, and TAnthony agrees, there will be backlash if we simply delete the number of columns and default everything to 30em that was using fixed columns. I checked the talk page history for Reflist, but I didn't see anyone discussing how to convert multiple column reflists to "em" widths. Redrose64 implied above that there may have been such a discussion; do you have a link to it? It would be helpful, if only to avoid re-litigating or making the same mistakes others have already learned from. Thanks.
And one other thought: It looks like most of you have larger screens than I do, so you are seeing two columns become three or four, for example. I think this is better than setting a wider "em" value by default (e.g. 40em) and having people with small screens see just one column. The editors put the Div col template in place with an expectation that there would be at least two columns, so we should try to preserve that intent. It looks like a default of 30em does that. – Jonesey95 (talk) 16:15, 15 January 2018 (UTC)
The reflist discussions go back almost four years and are spread over eight archive pages. Start at Template talk:Reflist/Archive 25 and work forward, searching for "columns" in each one. See also Wikipedia:Village pump (proposals)/Archive 141#Automatic column mode for references element. --Redrose64 🌹 (talk) 23:36, 16 January 2018 (UTC)
Thanks for the pointers. I had found the VPT discussion, and I read through the Reflist talk archive. For the most rational and conclusive discussion of deprecation and conversion of a fixed number of columns in favor of rendering columns based on column width and the width of the viewer's screen, see Template talk:Reflist/Archive 29.
The folks modifying Template:Reflist made a few choices that we should probably approach differently.
  • First, they decided to keep a single column when there are ten or fewer items in the reference list. I believe that if someone goes to the trouble of adding {{div col}} to a page, they are explicitly asking the page to render the subsequent text in multiple columns, as long as the viewer's screen is wide enough.
  • Second, at Reflist, the template allows editors to specify a number of columns, but it doesn't really work: When you use 1 the template gives you a single column while 2 will pretend you specified 30em. When using higher column counts, it will pretend you specified 25em. I think that rather than try to (poorly) translate column counts into em values, we should provide examples on the template's documentation page and let editors choose an em value that works for their needs. – Jonesey95 (talk) 04:43, 17 January 2018 (UTC)

Proposal for standardized changes (by bot or AWB)

Here's a straw proposal for standardized changes that could be made by a bot or by an AWB editor, written in faux regular expressions. We will probably want a bot, since we're looking at an article count of something like 45,000 to 60,000. Where "div col" appears on the left side below, we will also need to search for "colbegin", "div col start", "cols", "div col begin", and any other redirects to div col. 

{{div col|2}} → <s>{{div col}}</s> {{div col|colwidth=30em}}
{{div col|cols=2}} → <s>{{div col}}</s> {{div col|colwidth=30em}}
{{colbegin|2}} → <s>{{div col}}</s> {{div col|colwidth=30em}}
{{colbegin|cols=2}} → <s>{{div col}}</s> {{div col|colwidth=30em}}
(etc. for other redirects)
{{colbegin|3}} (or cols=3) → {{div col|colwidth=22em}}
{{colbegin|4}} (or cols=4) → {{div col|colwidth=18em}}
{{colbegin|5}} (or cols=5) → {{div col|colwidth=15em}}
{{colbegin|6}} (or cols=6) → {{div col|colwidth=13em}}
{{colbegin|7+}} (or cols=7+) → {{div col|colwidth=10em}} (any number of columns 7 or higher)
{{Columns-list|2| → {{Columns-list|colwidth=30em| (while we're here; also do for all redirects to this one)
{{Columns-list|3| → {{Columns-list|colwidth=22em| (and etc. as below)
{{div col||([0-9]em)}} → {{div col|colwidth=$1}}
{{div col|([0-9]em)}} → {{div col|colwidth=$1}} (as currently coded, this is an error, but fixable)
{{colend}} → {{div col end}} (replace all end template redirects with div col end)

The patterns above will take care of the vast majority of the deprecated parameters. There will be some instances remaining that can be handled manually, perhaps a few hundred or a thousand. – Jonesey95 (talk) 18:56, 15 January 2018 (UTC)

I'm fine with this, but if we're not going to add 30em for the 2 column conversions, we should perhaps note somehow in the edit summary that 30em is the default. Page watchers may not know this, and may be alarmed at the removals.— TAnthonyTalk 00:36, 16 January 2018 (UTC)
I have changed the proposal above to explicitly set |colwidth=30em where the number of columns was 2. – Jonesey95 (talk) 05:36, 12 March 2018 (UTC)
If you are going to change {{colbegin}} to {{div col}}, can you also do {{colend}} to {{div col end}} for consistency. -- WOSlinker (talk) 09:01, 16 January 2018 (UTC)
Good idea. I have added it to the list above. – Jonesey95 (talk) 13:57, 16 January 2018 (UTC)
I have also added {{Columns-list}} to the above list. It has had the columns parameter removed from the template, but it needs to have unnamed parameters converted to em values. It's another 10,000+ articles. – Jonesey95 (talk) 14:08, 16 January 2018 (UTC)
@Redrose64: Do you have an opinion on this? I recall no major pushback when we rolled out the reflist changes, though they may not have been implemented consistently. And I haven't gotten any negative reaction to the 2 column conversions and such I've been doing in the course of correcting unknown parameters.— TAnthonyTalk 00:21, 17 January 2018 (UTC)
Other than the fact that changing from the entirely natural {{divcol|2}} to the specialist knowledge {{div col|any number of ems that you like}} is one of the most user unfriendly ideas I have seen on Wikipedia, It should be noted that changing {{divcol|2}} to {{divcol|30em}} alters the intended (by the editor) division of a list into two columns into a list with three columns. This is enough to make me look for deprecated templates, just to make the bots screw them up. --Lineagegeek (talk) 00:19, 26 January 2018 (UTC)
The thing is, in most cases we should not be selecting numbers of columns at all, because what "looks good" to one editor will look completely different to many others, and may even negatively impact readability and the efficient use of available space. Reasonable ems allow column rendering dynamically based on the reader's settings and device. In your example above, an editor may have intended 2 columns, but if space allows for three or more, it would be preferred to 2 looong columns and a lot of wasted space.— TAnthonyTalk 01:05, 26 January 2018 (UTC)

I am glad that this discussion is taking place and I was in the process of making a bot for this (for practice, if not anything else) before I discovered this thread (GitHub WIP). @Jonesey95: What about the second unnamed parameter? I noticed that the above only deals with the first unnamed parameter? Also, what about if the first parameter has a number higher than 6? --TheSandDoctor (talk) 04:02, 12 March 2018 (UTC)

(I have unindented the above talk page entry, since it is really a new discussion item. Undo that change if it is improper.) Thanks for taking on this bot task! The second unnamed parameter is mentioned in the list above, though it's hard to find: {{div col||([0-9]em)}} → {{div col|colwidth=$1}}. By my reading of the template's code, when |2= is present, |1= is ignored, so in the bot run, |1= could be deleted when |2= is present. You might want to check the template's code on your own, and make this bot behavior explicit if you file a bot request.
As for the number of columns being greater than 6, there are only about 60 such instances of the template, according to the TemplateData monthly report, so I was thinking that those could be handled by hand after the bot run. Or we could choose some minimum columnwidth for anything greater than 6 columns, like 10em, and let editors tweak those few dozen pages manually after the bot run if they want to. I have added a line above for |cols=7+. – Jonesey95 (talk) 05:36, 12 March 2018 (UTC)
Bot is now done. While I am happy to include Columns-list's deprecated params, I feel that it would be better suited as a separate task (for BFRA purposes). What do you think Cyberpower678? If you think it would be appropriate to add it, I can do that without issue (in probably less than 10 minutes).
Also, @Lineagegeek:@Redrose64:@WOSlinker:@Lineagegeek: (Cyberpower678 (not double pinging as no point)) how do you feel about a bot doing this task? I have mock-run the bot through 20-30 of the pages in the category (printing its output to an input/output file instead of saving on-wiki) and it appears to have handled them without issue. If we are in agreement, I shall file a BFRA (pending the above). (To be clear) Again, I am happy to just consider this a practice exercise if need be and consensus is not reached. --TheSandDoctor (talk) 00:47, 13 March 2018 (UTC)
I have no issues with this. Go ahead and file one.—CYBERPOWER (Around) 01:24, 13 March 2018 (UTC)
@Cyberpower678: Thanks. Combined (including columns-list deprecated) or just the div col deprecated? --TheSandDoctor (talk) 01:59, 13 March 2018 (UTC)
I would prefer a combined bot. It seems like essentially the same set of tasks to me, with the same rationale behind the tasks and the same end goal. – Jonesey95 (talk) 03:47, 13 March 2018 (UTC)
@Jonesey95: A version has been made with columns-list added, just awaiting confirmation and will then file the BFRA (most likely tomorrow in my timezone). --TheSandDoctor (talk) 04:36, 13 March 2018 (UTC)
How does the code treat {{div col|1}}, which currently shows a single column? It looks like you convert that to 30em, which might not be right. Maybe set it to something like 100em? One of the other page watchers might know the best way to handle it. – Jonesey95 (talk) 04:53, 13 March 2018 (UTC)
You are correct Jonesey95, that is what it does. Your description/request above did not specify what to do in the case of 1 being the value, so I just picked what it was for 2. If you (or others) would like a different value (eg "100"), then I would happily change that (very minor change). --TheSandDoctor (talk) 04:59, 13 March 2018 (UTC)
I would say that for {{reflist|1}}{{div col|1}}, alter it to a simple {{reflist}}{{div col}}. --Redrose64 🌹 (talk) 19:33, 13 March 2018 (UTC)
Do you mean {{div col}}? The change you suggest would convert current one-column lists to lists with 30em column widths. If that is the consensus, it's OK with me, but it seems to go against the original intent of the editor who specified a single column. – Jonesey95 (talk) 20:01, 13 March 2018 (UTC)
Ping @Redrose64: --TheSandDoctor (talk) 20:15, 13 March 2018 (UTC)
Yes, that's what I meant. It seems odd for somebody to intend columnar formatting using a single column. Easier to simply omit the templates. --Redrose64 🌹 (talk) 00:21, 14 March 2018 (UTC)
Works for me. If someone really wants one column, they can set |colwidth=30em or remove the div col and div col end templates entirely. – Jonesey95 (talk) 03:57, 14 March 2018 (UTC)
sizes == 1 have now been set to not add the |colwidth= parameter (in bot). --TheSandDoctor (talk) 05:21, 14 March 2018 (UTC)
@Jonesey95:@Redrose64:@Cyberpower678:@WOSlinker:@TAnthony:@TheDJ:@Lineagegeek: The (combined) BRFA filed. --TheSandDoctor (talk) 16:44, 14 March 2018 (UTC)

Sandbox updated

I have updated the sandbox to remove support for the deprecated parameters |1=, |2=, and |cols=, which will be removed primarily by the bot discussed in the section immediately above. I have set the default {{div col}} rendering to use |colwidth=30em, as discussed above. The testcases page shows that the sandbox is working as designed, as far as I can tell. The sandbox should be put into production only after all of the deprecated parameters have been removed from template transclusions. – Jonesey95 (talk) 03:56, 14 March 2018 (UTC)

Ongoing discussion regarding Div col deprecated parameters task for DeprecatedFixerBot

A discussion is ongoing regarding DeprecatedFixerBot's BRFA and display changes on my talk page as a user has reported that they do not display as intended for them. Please feel free to take part. --TheSandDoctor Talk 05:13, 15 May 2018 (UTC)

Question

Hellou! I'm an administrator from the Serbo-Croatian Wikipedia and we've been having trouble with this template for some time now. I first noticed the issue four years ago while editing the article for the 2014 FIFA World Cup and it has persisted throughout the years until this very day. Namely, when I use {{Div col}} with 2 or 3 columns, irrelevant, it always breaks the columns unevenly (for example, when there are three columns and the number is not divisible by three, the middle column always has the largest number of rows; p.e. the section "Autogolovi" breaks 10 rows into a 3-4-3 form, instead of a 4-3-3 or a 4-4-2) or it stacks the columns from right to left, while it should be the exact opposite (p.e. same article, section "2 gola", it has a 4-5-5 form, instead of a 5-5-4; if you do that with two parameters, it creates a ridiculous 0-1-1 form); the same issue persists with two columns, if the number is not divisible by 2. The only instance when the template actually works is when the number of parameters is divisible by the number of columns.

So, I've browsed around this talk page. I'm using the latest version of Opera (54.something) on two computers (a PC with a standard screen and a widescreen laptop) and the problem persists despite the change of... well... scenery. The resolution and the quantity of space on these two screens is, of course, quite different. I've tried using Mozilla and Microsoft Edge, but the situation remains unchanged. The uneven breaking is the same on each screen, each resolution and with each browser. The same issue presents itself with {{Reflist}}, but it it is slightly less noticeable (p.e. here, it shows a 10-11, instead of a 11-10 break, but it is not noticeable firsthand because the text levels the columns).

On the other hand, when I access the same article on this Wikipedia, which uses the same template and the same parameters (the template code for {{Div col}} is equal on both projects), on each screen, each resolution and with each browser - the division is completely normal and even. Since I would like to finally, after so many years, solve this issue, I was wondering whether someone with experience or an administrator with knowledge could point me to a solution or visit our project and solve it himself? Thank you in advance! --Edgar Allan Poe (talk) 12:40, 2 July 2018 (UTC)

The point about {{div col}} (and {{reflist}} with columns) is that we don't specify where the columns should be broken; it is left entirely to the browser. We may expect different browsers to behave differently. All that we specify is a minimum column width (via the column-width property): the browser divides that into the available width in order to decide how many columns should be used. --Redrose64 🌹 (talk) 20:16, 2 July 2018 (UTC)
Note that the "cols" param is deprecated. Kendall-K1 (talk) 20:41, 2 July 2018 (UTC)
Yes, I quite understand that, but when I copy the exact same code from the English Wikipedia to our Wikipedia, the result is not the same. Namely, the triple scorers are divided, on our Wiki, 2-3-3, while the same code on this Wikipedia produces 3-3-2. So, there is absolutely no difference in the code. Also, I am using the same browser on the same laptop... so the only difference is the tab (or the Wikipedia project), not the browser. So, why does the same browser break columns differently on two different projects? --Edgar Allan Poe (talk) 21:17, 2 July 2018 (UTC)
I assume it has something to do with differences in the skins between the two wikis. Skins are implemented as css, so there is probably something in there that influences col rendering. You can set global css for all wikis, so you may be able to fix this for yourself if you want. Kendall-K1 (talk) 21:56, 2 July 2018 (UTC)
You may wish to examine differences between en:MediaWiki:Common.css and sh:MediaWiki:Common.css, in particular, search for 'div.columns'. Frietjes (talk) 22:00, 2 July 2018 (UTC)
Kendall-K1, thank you so very much! Your method worked :D Now it's finally working. I combined your method with the one suggested by Frietjes and it worked. So thank you both so much! Also, thanks to all the others that gave their input. I tried changing the whole Common.css for our Wiki, but that did not solve the problem, which is why I think that it's a more structural problem with the Serbo-Croatian Wikipedia, something I am going to discuss with my fellow admin, OC Ripper when I get the chance. Once more, thank you all for your assistance! Cheers! --Edgar Allan Poe (talk) 23:53, 2 July 2018 (UTC)

How to handle transclusions with deprecated parameters outside of article and template space

When we added deprecated parameter tracking to this template, we limited the categorization to article space, which is typical with templates that are used primarily in article space, such as infoboxes. This template is transcluded quite a bit outside of article space, however.

I used a variety of insource searches to find and fix transclusions of this template in Template space, and I got at least 99% of them.

While fixing some transclusions, I recently stumbled across a few remaining errors in Template space, so I have added tracking for Template space as well. That has turned up a few dozen deprecated parameters, mostly in template documentation pages.

How do we want to deal with transclusions of this template in namespaces other than Template and the article space? Do we need to fix them before updating the template? Do we just update the template from the sandbox and let people figure it out on their own in User/Wikipedia/etc. space? Should we expand the use of a hidden tracking category to all spaces after Template and article space are fixed? Should we show an error message in Preview mode?

My suggestion is to clear out the current tracking categories, update the template, and then enable the "unsupported parameter" category for all namespaces. I am open to other reasoned opinions, of course. – Jonesey95 (talk) 05:19, 30 June 2018 (UTC)

I did not get any feedback on this question, so I have put the sandbox version into production. Error messages will appear in preview for all unsupported parameters, but pages will be categorized in the unknown parameter tracking category only in article space. – Jonesey95 (talk) 15:07, 12 July 2018 (UTC)

Help

How do I make the "colour key for parties" here (just after the lead) appear as two columns? Specifying a col width doesn't seem to work. (It used to be fine until a bot changed it to div col).—indopug (talk) 11:56, 18 July 2018 (UTC)

It looks like the div col template (which is the same as colbegin) doesn't make columns inside a table when |colwidth= is used. I used wikitable syntax to make a real table. – Jonesey95 (talk) 14:03, 18 July 2018 (UTC)
we really shouldn't be adding WP:LISTGAPs there, and after the change the columns are no longer vertical aligned. I will revert the damage. Frietjes (talk) 14:13, 18 July 2018 (UTC)

1= and 2= and cols= no longer supported

The long-deprecated parameters to set a specific number of columns have been completely eliminated from Template and article space, so I have implemented the changes to the template as detailed above. The |cols= parameters, as well as the unnamed parameters |1= and |2=, are no longer supported in this template. Use |colwidth= with an "em" value, like "15em" or "30em", to specify a column width. The default is 30em if no value is supplied. – Jonesey95 (talk) 15:10, 12 July 2018 (UTC)

I just noticed that {{Div col||##em}} seems to also be no longer supported—at least I received an error message when I attempted to use it. :-/ —DocWatson42 (talk) 04:07, 13 July 2018 (UTC)
Right, as explained in the header of this section and my initial post. Your example is a usage of the second unnamed parameter, also known as |2=, which is no longer supported. See the discussion above and the template's documentation.
Unnamed parameters are difficult to deal with when there is more than one and changes to the template are needed. We needed to remove the |cols= parameter, which was also |1=, the first unnamed parameter. If we had simply removed it from the template, then |2=, which is also |colwidth=, wouldn't have worked right anymore. It's better to just rip the bandage off and remove support for unnamed parameters completely (after converting all template and article space usages to named parameters, which we did). The template becomes a little less space-efficient but a lot easier to interpret and understand. – Jonesey95 (talk) 06:18, 13 July 2018 (UTC)
"Ouch." ^_- Thank you for the explanation. DocWatson42 (talk) 07:35, 14 July 2018 (UTC)—
Ouch indeed. Broke a lot of usages, because I have replaced deprecated "2" and "3" columns with {{Div col||##em}} in a whole lot of articles. Some will now look a little odd unless found and fixed. I only say this because I also used the replacement code on my user pages and found the need to fix them after this deletion of params.  Paine Ellsworth  put'r there  20:18, 15 July 2018 (UTC)
Please link to articles that are currently broken, and I will fix them. Category:Pages using div col with unknown parameters is currently empty, which means that there should not be any articles with the unsupported parameters listed above. Pages in other namespaces are not included in the tracking category, although that could be changed if there is a desire to do so. – Jonesey95 (talk) 20:41, 15 July 2018 (UTC)
No, Jonesey95, as long as mainspace is covered, that's the important thing. Users will figure it out if they've used Div col on their user pages. Thank you for your work, as I realize that this was an improvement.  Paine Ellsworth  put'r there  16:13, 16 July 2018 (UTC)
Thank you for the appreciation. Often making improvements causes difficulty for editors, even when the end result is something everybody wants (or should want, said the arrogant template editor...). Change can be difficult. I tried to make this one as painless as possible. – Jonesey95 (talk) 01:56, 17 July 2018 (UTC)
heh, I've been told that one good thing about "ouch" and pain is that it's proof we're still alive. Be well.  Paine  12:29, 17 July 2018 (UTC)
  • I'd strongly recommend notifying affected users and projects. I can't be the only guy who just found out some template change had fucked up their userpage without warning and not every user will have the knowledge level required to figure it out by themselves. Ben · Salvidrim! ✉ 01:56, 25 July 2018 (UTC)
Also I've read through discussions higher up but I can't find the consensus of irremediable technical limitation that prompted the deprecation of specifying a number of a columns instead of a column width. I get changing the default from 2cols to 30em of course. Ben · Salvidrim! ✉ 02:07, 25 July 2018 (UTC)
What you call "fucked up", a programmer might call "failed gracefully by creating columns of minimum width 30em". In any event, the |cols= parameter was deprecated in 2014, since it was not compatible with mobile devices or small screens, and made columns that were undesirably wide on very large screens. {{Reflist}} was modified in a similar way in the past couple of years, for the same reasons. See WP:RESOL for a note on accessibility issues as well.
A bot and human editors cleaned up all deprecated parameters in {{Div col}} in article space and template space, but since the template fails gracefully, it did not appear necessary to add an error message or a tracking category in other namespaces. If you edit a page in Preview mode, you will see a red error message that explains to use colwidth= instead, but readers viewing pages normally will not be affected negatively. I considered adding a red error message to the displayed (non-preview) version of this template, but did not do so. I will likely do so for {{Columns-list}}, because the failure mode shows the first unnamed parameter instead of the desired content (see the discussion above in this section about the perils of unnamed parameters). I am currently fixing {{Columns-list}} on all non-Draft, non-sandbox pages on the English Wikipedia before removing support for fixed column counts there.
If you still want a fixed number of columns despite the accessibility and screen size problems, see the "See also" section of the documentation for this template. – Jonesey95 (talk) 04:36, 25 July 2018 (UTC)
Apologies if "fucked up" was too strong wording -- what I meant was, I had columns, and the change you made to the template changed my userpage to have NO columns (not Xem)... hence, the change broke my userpage (made it display in a way that wasn't intended and hampered readability (subjectively)). To claim the template code change did "not affect viewers" or did not affect the rendering of my userpage is not an accurate reflection of reality. However, in any case I'm very aware of accessibility and compatibility issues and don't mind the change from fixed-format to device/screen/resolution-relative formatting, I think it's a net improvement for damn sure in general, although as long as Mediawiki allows custom userpages, I'll stick to divstyles to define my columns. However I maintain that a warning, notification, etc. that "your userpage was changed because it uses deprecated parameters, here's a brief summary of why and here's a few ideas on how to fix it" should have (and should still) go out to users whose userpages are impacted. Ben · Salvidrim! ✉ 06:01, 25 July 2018 (UTC)

Yeh_Un_Dinon_Ki_Baat_Hai#Cast

How do I force/recomend a new column on a heading? The intent is that the cast lists should have their headings verticaly aligned. ShakespeareFan00 (talk) 11:35, 5 August 2018 (UTC)

Not by using {{div col}}, where the column breaks are determined by the browser based on a number of factors including the space available. Instead, try using {{col-begin}}/{{col-break}}/{{col-end}}. --Redrose64 🌹 (talk) 14:51, 5 August 2018 (UTC)
Noted but that currently generates mismatched P tags. ShakespeareFan00 (talk) 20:17, 5 August 2018 (UTC)
ShakespeareFan00, looking at the source for those three templates, I don't see any <p> without the corresponding </p>. not sure why we are using <p>...</p> in those templates, but they seem to be all matched. Frietjes (talk) 20:35, 5 August 2018 (UTC)
That's why I'm puzzled as to their use generating HUNDREDS of errors.ShakespeareFan00 (talk) 20:36, 5 August 2018 (UTC)
ShakespeareFan00, can you provide a pointer to one. Frietjes (talk) 20:49, 5 August 2018 (UTC)
https://en.wikipedia.org/w/index.php?title=Agricultural_science&action=edit&section=6 for starters, And many of the missing P items listed on https://en.wikipedia.org/w/index.php?title=Special:LintErrors/missing-end-tag&dir=prev&namespace=0. This happens because <P></P> is being (incorrectly) used as a context break, because mediawiki table syntyax is so poorly implemented in respect of transclusion, it can't recognise the appropriate SOL context for the start of table data item. If there was ever any willingness to ACTUALLY fix long standing issues instead of creating hacks to paper over design flaws... It's a good thing the parser change has exposed the cracking plaster <evil grin> ShakespeareFan00 (talk) 20:57, 5 August 2018 (UTC)
In any case the

hack will eventually break when the parser is updated to just strip out blank tag groups entirely...ShakespeareFan00 (talk) 20:58, 5 August 2018 (UTC)
I'm almost at the point of IAR stripping ALL multi-col use. ShakespeareFan00 (talk) 21:01, 5 August 2018 (UTC)
Why have you posted an edit link? What am I supposed to be looking for there? --Redrose64 🌹 (talk) 21:54, 5 August 2018 (UTC)
Do a LintError check with the assistance of User:PerfektesChaos/js/lintHint, and the issue of the mismatched P should present itself. The mismatching should show up as the col-break or col-end templates. 22:05, 5 August 2018 (UTC)
I can't find any unmatched <p> tags, either by viewing the page HTML, using my browser's "Inspect element" feature, or by putting the templates and their content through Special:ExpandTemplates. I can find some instances of empty <p></p> pairs, generated by {{col-break}}; but they all balance correctly.
Again, why have you given an edit link? --Redrose64 🌹 (talk) 22:21, 5 August 2018 (UTC)
In fact, thinking about this some more, an unmatched <p> tag should not be a problem, since the HTML specs have all allowed the omission of the </p> tag (implicitly to HTML 2.0, explicitly from HTML 3.2 on). Anything that marks this as an "error" must therefore be in error itself. --Redrose64 🌹 (talk) 22:40, 5 August 2018 (UTC)
@Redrose64 and ShakespeareFan00: we should probably continue this discussion at Template talk:Col-break since there is already a thread started there. Frietjes (talk) 23:28, 5 August 2018 (UTC)

Template appears to be disabled

Someone appears to have disabled Template:Div col. It no longer works in HVAC#See also and every other article where the template is used in any section. Peter Horn User talk 12:52, 10 August 2018 (UTC)

It works just fine at Wikipedia:Meetup/UK#Oxford. I think that the problem with HVAC#See also is that in the parameter |colwidth=36 there are no units - so your browser has no idea what there should be 36 of - inches, millimetres, pixels, or elephants. Valid units include: em, ex, in, cm, mm, pt, pc, px as detailed at CSS Values and Units Module Level 3. --Redrose64 🌹 (talk) 13:14, 10 August 2018 (UTC)
also works where you added it here. Frietjes (talk) 13:34, 10 August 2018 (UTC)
Not quite, I had to change Level crossing#See also from colwidth=30em to colwidth=20em to make it work. Peter Horn User talk 15:52, 10 August 2018 (UTC)
This version has |colwidth=30em. For me, it shows as a single column for a screen that is narrower than about 1000px, above that it goes to two columns. --Redrose64 🌹 (talk) 17:02, 10 August 2018 (UTC)
I have since revised that to |colwidth=20em getting the two columns I wanted. Peter Horn User talk 21:58, 10 August 2018 (UTC)

Request to fix TemplateData

Can a willing editor please fix the TemplateData section to match the human-readable portion of the documentation? All references to |cols=, |1=, and |2= should be removed, as they are no longer supported. I don't edit TemplateData code; it's a long story. Thanks in advance. – Jonesey95 (talk) 20:30, 21 November 2018 (UTC)

 Done — JJMC89 (T·C) 23:24, 21 November 2018 (UTC)

Article histories and old versions of articles using this template

Is there a way to get old versions of articles to display properly? Example. Carcharoth (talk) 11:43, 17 April 2019 (UTC)

I've updated Template:Columns-list so that it works better. -- WOSlinker (talk) 11:53, 17 April 2019 (UTC)
Thank you. That was remarkably painless and easy to get fixed. :-) Carcharoth (talk) 11:57, 17 April 2019 (UTC)

"rem"

An editor is changing "em" to "rem".[4] Does "rem" have any effect in this template? --AussieLegend (✉) 16:03, 10 September 2019 (UTC)

The template documentation explains that the colwidth parameter can be specified in any CSS unit of measure. Lmatt (talk) 17:39, 10 September 2019 (UTC)
The article that you linked to also says that "if adopted" rem will be added but you have not addressed this at any of the articles where you have been adding rem, even when asked to. --AussieLegend (✉) 17:47, 10 September 2019 (UTC)
@AussieLegend: The status of CSS Values and Units Module Level 3 as a W3C Recommendation is not particularly relevant. CSS Multi-column Layout Module Level 1 is not currently "adopted" as a W3C Recommendation either, but enwiki still makes use of multi-coumn layouts. rem (root em) units actually have very wide browser support compared to the column-width property (98.87% v 92.7%). Lmatt (talk) 18:56, 10 September 2019 (UTC)
@Lmatt: You can't seriously imagine that Wikipedia editors are going to sit here and argue with you about specific minutiae of the multitudinous W3C standards. Look at what the template documentation says; see section Parmeters or Columns, for example. Do you see anything there about "rem"? No. Whether or not it is an acceptable unit in the W3C CSS recommendation or not, is beside the point. This is the Wikipedia project, and we are dealing with mostly tech-naive editors, who have a ton of problems just dealing with signing their name, or figuring out how to make a hyperlink or a proper H3 section header, and we don't need to point them to offsite technical references and harangue them about obscure units; they'd just run away screaming, and we'd never hear from them again. Editor retention is a serious issue and problem at Wikipedia, and little things like this, really don't help. It's hard to see any justification for this change, and it's starting to be disruptive. Knock it off. Adding AussieLegend. Mathglot (talk) 22:18, 10 September 2019 (UTC)
It looks like the original question was "Does 'rem' have any effect in this template?", and it looks (to me, using my web browser) like "rem" works, i.e. it makes columns of the specified width. Works for me. Perhaps the documentation needs to be updated, or a broader question about the use of "rem" and other new CSS length specifiers should be raised at WP:VPT instead of this backwater of a template talk page. – Jonesey95 (talk) 23:15, 10 September 2019 (UTC)
Agree, it should be raised at wp:vpt and if its already supported then documentation should be updated---- Work permit (talk) 00:36, 11 September 2019 (UTC)
I see that no VPT thread has yet been raised, so I'll post here. Templates do not "support" units of length; they are passed straight through to your browser via declarations such as -moz-column-width: 30rem; -webkit-column-width: 30rem; column-width: 30rem; specified in the style= attribute of a <div>...</div> element. It is then up to your browser to decide how to handle it. Whilst the width specified by 30rem may well give the same visual effect as 35em for Lmatt (talk · contribs), that will be their personal experience and may not be shared by other people, who are unlikely to have exactly the same system setup (machine, screen, operating system, browser, installed fonts, personal CSS, personal JavaScript, etc.). So some users may see two columns for both forms, others may see two columns for one but three (or just one) for the other.
I have this observation though: because no fallback to the widely-supported em unit is being specified and not all browsers support the rem unit, such browsers will show a single column. Yes, not all browsers support the column-width: property (or the vendor-specific properties -moz-column-width: and -webkit-column-width:), and will also show a single column, but for those there is nothing that we can do in the form of a fallback. --Redrose64 🌹 (talk) 12:12, 11 September 2019 (UTC)

This is a backwater, and VPT might be a better venue, but I can't agree that the documentation should be updated to reflect the current state of CSS units in W3C. And this, from someone who has championed documentation all my life, including here, and backed it up with action here and elsewhere. The reason is, that excessive duplication of all the myriad possibilities supported by browsers in our documentation will merely confuse and scare non-tech savvy people away. The current "em" description is mysterious enough for most, but documented. Let's not snow our editors by complicating that with px, pt, cm, in, rem, and what-all else. The documentation is sufficient the way it is, with the possible exception of an external link to a comprehensive W3C document, for those code-jockeys who want to show off with their knowledge of the latest units nobody else has heard of. In this case, the user-friendly thing to do is not to encumber the documentation with every possible unit under the sun, but to leave it like it is, except for the additional external link. Mathglot (talk) 10:24, 12 September 2019 (UTC)

Yes, one thing is certain: all current browsers (and their versions going back twenty or so years) understand the eight basic units (em ex px in cm mm pt pc); these are quite sufficient for the majority of purposes. Even those are more choice than I need - I've never yet seen pc used on any webpage, and the instances of in, cm and mm are exceedingly rare. I suggest that we confine examples to em and ex. --Redrose64 🌹 (talk) 19:54, 12 September 2019 (UTC)

Actual template data

I want to add this template to a site over on Wikia, but I admit to being a bit of a noob and I'm having some trouble getting my head around it if it is there in the documentation. Could someone give me a hand? This will be very useful on the Wikia site I think Footy Freak7 (talk) 09:45, 20 September 2019 (UTC)

We are happy to help, but it is unclear what you are asking. Please rephrase your question, maybe with a link to your Wikia site. – Jonesey95 (talk) 17:03, 20 September 2019 (UTC)
HUH? I thought I made it clear. There is no actual coding on the template. I want the coding and I can't find it even in the documentation. How did I not make that clear? It's not my Wikia site by the way. I just edit on it. Footy Freak7 (talk) 00:16, 23 September 2019 (UTC)
To see the code that generates this template, or any page on any Wikipedia site, click the Edit link at the top of the page. On some pages, the link says View Source instead. – Jonesey95 (talk) 01:27, 23 September 2019 (UTC)
The coding that came up was inserted and gives a script error. Here is the link. Footy Freak7 (talk) 10:13, 26 September 2019 (UTC)
The template is invoking a module called Module:Check for unknown parameters, which does not exist on your wiki. That might be the problem. You are also missing Template:Main other and Template:Column-width. – Jonesey95 (talk) 14:54, 26 September 2019 (UTC)

What has happened here?

I use {{Div col|rules=yes}}/{{Div col end}} a lot on User:Huldra/Robinson, as I want to imitate what the Robinson pages look like, say p. 116.

However, suddenly the above Div col has no effect...what has changed, and how can I get it back? Huldra (talk) 23:05, 29 March 2020 (UTC)

I'm seeing columns with rules between them on that page. If you have a narrow window, you could try making it bigger, or you could try setting |colwidth=20em or something else smaller than the default 30em. – Jonesey95 (talk) 23:49, 29 March 2020 (UTC)
Now it suddenly works again! (And no: no difference in window size) ..magic? Huldra (talk) 23:59, 29 March 2020 (UTC)

Table/div col combination queries

Following the result of an RfC on football squad template, I'm trying to make a responsive table using div col, which I've partially achieved at User:Number 57/sandbox/squad.

One issue is the heading - there is an initial heading (as desired), but currently I have only been able to add the second one by turning a normal row into the appearance of a heading, which looks ok in two columns (and does resolve the issue of fb squad currently appearing as two side-by-side tables), but when it goes into single column mode, the heading appears again halfway down the list.

To resolve this, I was wondering whether it's possible to have headers in div col, and whether they can be repeated at the top of each column?

Separately, is it possible to to force columns closer together rather than them displaying at set distances apart on the page? Cheers, Number 57 21:29, 22 May 2020 (UTC)

You are misusing {{div col}}, it is not intended to enclose tables. The point about it is that you feed it either plain text or a single contiguous list and let the browser work out where the column breaks are going to be. You cannot put artificial breaks anywhere: not only can you not be certain that the position that you have chosen will be the top of a column, it violates accessibility guidelines.
The minimum column width is set by the |colwidth= parameter, it defaults to 30em. The width of the space between the columns (the "gutter") is set by the |gap= parameter, which defaults to 1em. --Redrose64 🌹 (talk) 22:28, 22 May 2020 (UTC)
I'm not looking to put artificial breaks anywhere – the reason I was asking here was to find a solution that avoids using artificial breaks. Hence asking whether its possible to have a header for div col that is repeated every time it splits into another column.
I've tried setting the gap to 0em, but there is still a significant gap between the columns – am I missing something? Number 57 23:05, 22 May 2020 (UTC)

{Div col} not working

I have tried using {{colbegin}} and {{Div col}} for filmography section in the Wikipage Yajamana (2000 film). Though both the templates seemed working when viewed in "Preview", but after the final save, they seem to give no effect. Or am I missing something? DRAGON BOOSTER ★ 10:55, 31 July 2020 (UTC).

@DRAGON BOOSTER: is that better now? Mathglot (talk) 11:17, 31 July 2020 (UTC)
@Mathglot: Thank-you for the fix and the reply. Quick question though, why didn't {{Colbegin}} and {{div col}} with |30em work? Similar case, Chintakayala Ravi where in now, when I have changed from 30em to 20em seems working somehow. regards, DRAGON BOOSTER ★ 11:07, 1 August 2020 (UTC).
@DRAGON BOOSTER: Not sure, but do a test: next time you feel it isn't working, try dragging the window border on your computer to make it wider, and see if that fixes it. If you are on a handheld device, it may be that there just isn't enough horizontal room for it. Mathglot (talk) 11:15, 1 August 2020 (UTC)
@Mathglot: Ok.. I'll try that. Thank-you. regards, DRAGON BOOSTER ★ 12:57, 1 August 2020 (UTC).
In your browser window, there isn't enough space for two 30-em-wide columns between the left margin and the infobox. In other people's windows that are wider, there is. If you change the Zoom level of your web browser, you should see it add more columns as everything is rendered smaller. – Jonesey95 (talk) 13:23, 1 August 2020 (UTC)

Removed rules customization and column styles templates

I've made a change today pulling from sandbox that does the following:

  1. Removes the customization of |rules= i.e. |rules=10px dotted blue (|rules=yes remains). Very few pages used this customization in the wild; where there were, it was generally inappropriately styled. Users who need to customize the rules can use |style= to workaround this removal.
    • Corollary: Added rules styling directly to the TemplateStyles.
  2. Removes the reliance on the various column styles templates. Recent research at WT:ACCESS#Group of users interested in changes to CSS indicates they are not generally necessary (and I'll be TFDing them accordingly at some point Soon).
  3. I already did this, but the default width is in TemplateStyles rather than hard coded, so 30em disappeared from the template.

--Izno (talk) 04:58, 5 January 2021 (UTC)

Enumerated/standard widths

I'd like to introduce some standard widths into the CSS for this template. Right now, we have a lot of people picking out whatever width they please whereas I think we could reasonably support some extra and not deal with the inline CSS. (I am not sure it's a good idea, but there it is.) I almost pushed something live with my post above but couldn't decide on some naming and whether this was something that would be wanted by anyone else.

What I had in mind was something like the following: |widthclass= with keywords third, half, two-thirds, big-two-thirds corresponding to column widths of 10, 15, 20, and 25 em. (And we could go larger than 30 as well, with key words like larger at 35em and large at 40em.)

The rationale in particular: I've been finding that names like to fit into about 15em and sometimes longer names 20em as I've been going along removing {{columns}} and thought it might be nice to have the keyword to go along with it.

As you can see, my naming sucks. (Were it only the case that |colwidth= were available. Eyeshrug.) --Izno (talk) 06:42, 5 January 2021 (UTC)

Unfortunately, I agree about your naming. I think it would make more sense to provide three or four examples that people could copy, using the existing widths. Lists of people, lists of countries, lists of things with long names. – Jonesey95 (talk) 15:31, 5 January 2021 (UTC)
Please don't do this. It suggests that by using these "keywords", users would expect there to be an exact number of columns (two, three, etc.) which is what we are trying to get away from, because different devices have different widths. A column width that yields three columns for the user that specifies that figure may yield fewer columns on another user's device (a smartphone) or many more on a 10240px-wide 21:9 monitor (they do exist). --Redrose64 🌹 (talk) 20:27, 5 January 2021 (UTC)
I don't agree with users would expect there to be an exact number of columns; good naming (again, I was spitballing the above names) should suffice (and for everyone else, there's the documentation). "Half" and "full" and "large" (15, 30, 40 em) were the ones I had spitballed I think were sufficiently different from anything you could find in the column-count direction to be confused.
Even if we don't do that, we could also do something like processing the |colwidth= input and instead of applying the column-width directly, round/ceiling/floor to the nearest class value (at least for widths specified in em)? --Izno (talk) 23:44, 5 January 2021 (UTC)
Naming things is hard. I find all of these naming suggestions confusing. Are you trying for something like "narrow" and "wide"? If I am understanding, you want adjectives to describe how wide the columns are without the editors having to learn how big an "em" is. – Jonesey95 (talk) 02:30, 6 January 2021 (UTC)
Yes, that's the intent. Half and full were more objective to me as being related to the standard (30em). --Izno (talk) 04:44, 8 January 2021 (UTC)
Retrieved from "https://mdwiki.org/wiki/Template_talk:Div_col/Archive_1"