Template talk:Div col

From WikiProjectMed
(Redirected from Template talk:Div col end)
Jump to navigation Jump to search

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)[]
Bug was confirmed. I added a bit about it being an issue for N columns and N-1 rules as well as the basic 2 and 1 case. --Izno (talk) 04:48, 8 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)[]
Okay, so I added a few others to the sandbox. Browsers (Firefox at least) will cut content into smaller columns even if there are sublists, if it thinks things are unbalanced enough. "column-avoid" is exactly how it works today-- it's a suggestion, not a requirement for the browser. --Izno (talk) 01:28, 27 January 2021 (UTC)[]
 Not done for now: please establish a consensus for this alteration before using the {{edit template-protected}} template. Elliot321 (talk | contribs) 07:07, 21 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)[]
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)[]