Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Difficult to style columns #12028

Closed
overcatbe opened this issue Nov 18, 2018 · 4 comments
Closed

Difficult to style columns #12028

overcatbe opened this issue Nov 18, 2018 · 4 comments
Labels
[Block] Columns Affects the Columns Block [Type] Feedback Issues that relate purely to feedback on a feature that isn't necessarily actionable

Comments

@overcatbe
Copy link

overcatbe commented Nov 18, 2018

Hi guys.
I am not at all thrilled about your work on the columns block.
Like, could you FINALLY decide how you wanna handle it?

As i see it you have following possibilities:
1 - enable the columns, let them have their divs, and let US create the css for responsibility etc. This is the way you handled it previously, so STUCK WITH IT, please

2 - enable the columns, add the code, ... - yeah, you've tried. BUT - you've added some 32px here, some 32 px there, and it will just not suit anybody, because this is not the way this coding should be done. You did this without warning. Every page will have it's own breaking points, and frankly where did you get the 32 px from? Card reading?

3 - enable the columns, add the code to make them responsive, ADD the possibilities (in admin) to fill in stuff like breaking points, margins, wrap and padding. This would be the most user-friendly way.

The first possibility is good for coders, the third is good for an average user. But the second one i described and which you decided to force on us is just wrong.

Enough, this rant ends here. Please reconsider to add the code as described in 3, or revert to 1.
Thanks much

EDIT - also, before the last update THERE HAS BEEN a possibility of adding a css class selector to EVERY column. Why on earth has this been removed?

@earnjam earnjam added [Type] Feedback Issues that relate purely to feedback on a feature that isn't necessarily actionable [Block] Columns Affects the Columns Block labels Nov 18, 2018
@swissspidy swissspidy changed the title COLUMNS Difficult to style columns Nov 18, 2018
@plumbweb-thad
Copy link

I'm not sure I share quite the exact same concerns as @overcatbe, but I agree that it could be a little easier to style columns. I'm not sure if there is a better way to override the default gutter and responsive breakpoints, but I was doing so without too much trouble in my CSS, but that fell apart in the 6.0 release since the class "has-x-columns" was removed.

I commonly use 2, 3, or 4 columns and now they all have to jump to a single column at the same time since there is no way to differentiate between them, versus allowing 4 columns to first break to 2 columns and then to a single.

@cr0ybot
Copy link
Contributor

cr0ybot commented Aug 8, 2019

Could I suggest an approach for default column styling that might be a bit easier to override?

Currently, the columns are styled generally like this (some irrelevant styles omitted):

.wp-block-columns {
  display: flex;
  margin-bottom: 28px;
  flex-wrap: wrap;
}
.wp-block-column {
    margin-bottom: 1em;
    flex-grow: 1;
    min-width: 0;
}
@media (min-width: 600px) {
  .wp-block-column:nth-child(even) {
      margin-left: 32px;
  }
  .wp-block-column {
      flex-basis: calc(50% - 16px);
      flex-grow: 0;
  }
}
@media (min-width: 782px) {
  .wp-block-columns {
    flex-wrap: nowrap;
  }
  .wp-block-column:not(:first-child) {
    margin-left: 32px;
  }
}

Right away, we can see that we're mixing px and em units for margins, and 2 separate breakpoints are defined which apply margins differently. Having to hunt down breakpoints and pseudo-class selectors to override in a theme is not fun.

The nth-child(even) selector is meant to add margin between two 50% wide columns after 600 wide, but this no longer works with the individual column flex-basis system and just introduces another layer of unnecessary specificity. After 782 wide, columns are set to nowrap and all but the first get a left margin.

We can eliminate all of the column margin runaround by utilizing the negative margin technique:

.wp-block-columns {
  margin: -16px;
}
.wp-block-column {
  margin: 16px;
}

This creates a 32px gutter between columns no matter how the columns are wrapping, and it's only 2 properties to override without additional breakpoint specificity. The only issue here is that, if not within a container, the negative right margin will create overflow on the right side of the screen.

Perhaps something like this would be safer:

.wp-block-columns {
  margin-left -16px;
}
.wp-block-column {
  margin: 0 0 16px 16px;
}

Here there is no concern about overflow on the right or bottom side.

As for the flex-wrap situation, I'm not sure I agree with setting specific breakpoints to force a 2-column layout. Instead of setting a flex-basis percentage on the column, if you had the option to use px units, or set a minimum and/or maximum width, the columns could wrap naturally without the need for breakpoints.

@likethegoddess
Copy link

likethegoddess commented Aug 27, 2019

Using specifying left margins on .wp-block-column only works well for two-column layouts. The following removes the current excess space on the right on three+ columns layouts while avoiding the use of a negative margin container.

.wp-block-column:not(:first-child) { margin-left: 16px; }

.wp-block-column:not(:last-child) { margin-right: 16px; }

@youknowriad
Copy link
Contributor

Thanks for the feedback.

The columns block saw several updates recently and there's ongoing work to make styling in the editor easier tracked here #7770

I'm closing this issue now, please consider opening more specific issues if needed as these will be more actionable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Block] Columns Affects the Columns Block [Type] Feedback Issues that relate purely to feedback on a feature that isn't necessarily actionable
Projects
None yet
Development

No branches or pull requests

6 participants