Template talk:Div col

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)

• Done. -- SatyrTN (talk / contribs) 05:16, 7 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)

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)

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)

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)

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)

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)

 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)

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)

• Anini-y, Antique
• Barbaza, Antique
• Belison, Antique

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)

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)

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)

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

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)

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 (Template:Padlr) 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> (Template:Padlr) to the template's noinclude section before the Template:Tnf.

The code was then reorganized to make it easier to follow ([1]; 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: (Template:Padlr) ... (Template:Padlr) ... [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

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

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

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

<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 Template:Tnf 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 Template:Tnf to hand, how about:

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

<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 Template:Tnf. 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)

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)