Template talk:Div col

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)

Rules parameter adds extra line to end

The rules parameter incorrectly places a vertical line after the last column, given the columns aren't as wide as the window. You can see this effect with one to two items, or with a wider window, three to four items. The vertical line should be placed between existing columns, not to the right of them.

• Item 1
• Item 2

Jroberson108 (talk) 23:50, 9 November 2020 (UTC)

I have added a test case. It looks fine to me in Firefox for Mac (two columns with a rule in between). In Safari for Mac, I see a blank, ruled column between items 1 and 2, with a rule following item 2. In Chrome, I see two columns with a rule in between, then a rule to the right of the second column. So it looks correct in only one out of three browsers for me. – Jonesey95 (talk) 00:08, 10 November 2020 (UTC)

On Windows 7, it looks fine in Firefox, but has the extra line in Chrome. On Android phone, it looks fine in both Firefox and Chrome. Jroberson108 (talk) 00:43, 10 November 2020 (UTC)

Izno, while you are messing about with this template, do you have any interest in troubleshooting this one? – Jonesey95 (talk) 06:00, 5 January 2021 (UTC)

Displays with 2 rules in Chromium Edge for Windows 10 and Chrome for Android for me (Chrome is up to date but my phone OS is old.) This is probably an upstream task for Chromium rendering. I don't see a task in the relevant Chromium bug project.

Displays correctly in both Firefox Quantum and Firefox Daylight.

Fun stuff, neither line displays for me on the mobile website for either Chrome or Firefox. Does MobileFrontend just not care about any Tstyles? :) This style seems fairly benign... --Izno (talk) 06:15, 5 January 2021 (UTC)

Now filed at 1163025. --Izno (talk) 06:33, 5 January 2021 (UTC)

• Item 1
• Item 2
• Item 3
• Item 4
• Item 5
• Item 6

Add option to disable break-inside: avoid-column;

The current no column break behavior is actively harmful for those who need multilevel lists. The CSS should either be removed completely (since it is redundant with a {{no col break}} template), be hidden behind a switch (as a class), or at least a class should be added to allow for restoring it to the original. An example to play with is at https://jsbin.com/hufotaq/edit.

The first option is trivial. I think it makes the most sense, but it can be quite intrusive; some weighing is required.

The second option requires the addition of a parameter to the template. Simply change the first line of the template to have <div class="div-col {{#ifeq:{{{small|}}}|yes|div-col-small}} {{#ifeq:{{{nobreak|}}}|yes|div-col-nb}}" instead of <div class="div-col {{#ifeq:{{{small|}}}|yes|div-col-small}}". After that, replace .div-col li, .div-col dd with .div-col-nb li, div-col-nb dd, where div-col-nb is the name of the new class. (It also causes immediate global change, but a nobreak can be easily applied to all elements for unpleasant-looking lists.)

The third, least intrusive, option also requires the addition of a parameter. Change the first line of the template to have <div class="div-col {{#ifeq:{{{small|}}}|yes|div-col-small}} {{#ifeq:{{{allowbreak|}}}|yes|div-col-brk}}" instead of <div class="div-col {{#ifeq:{{{small|}}}|yes|div-col-small}}". After that, add the following to the CSS:

/* Allow break between columns */
.div-col.div-col-brk li, /* Over-specifying is required to up the importance */
.div-col.div-col-brk dd {
	page-break-inside: inherit;
	break-inside: inherit;
}

(We sadly cannot make a template called {{yes col break}}. The avoid-column directive on the enclosing element takes precedence.)

--Artoria2e5 🌉 15:09, 4 January 2021 (UTC)

@Artoria2e5: Based on my review while working on removing Template:Columns, the general case is not a multilevel list, so I would not support removing this from the default appearance. That's ignoring the fact that this has been in this template's CSS since Forever (via the column class prior to my update).

Overspecifying in your CSS is not generally necessary as the last applicable CSS applies. I don't imagine this would be "first".

We sadly cannot make a template called {{yes col break}}. This is not strictly true; if we were interested we could make this more meta-templatey and add some sort of |child templatestyles= or |between templatestyles= (or something of the latter) which would allow you to insert another template/templatestyles page (probably the former for this template) between the templatestyles tag and the opening div.

Can you put something in a personal sandbox so we can see the behavior at issue? This bit of the CSS is not something I'm familiar with and MDN can be a little lackluster with its examples at times. --Izno (talk) 03:58, 5 January 2021 (UTC)

Izno, I put the thing into the normal Template sandbox. See Template:Div_col/testcases#allow_break for how it looks. (It will work a lot better with a rule, I will say that.)

PS. The main article use I have right now is ATP-binding_cassette_transporter#Cross-species_subfamilies.--Artoria2e5 🌉 09:49, 5 January 2021 (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)