New parameter for lost-waffle to not override height

Question

New parameter for lost-waffle to not override height

elgandoz opened this issue 6 years ago · comments

Is this a feature request or a bug report?
Feature request (although it may be considered a bug as well).

What is the current behavior?
lost-waffle set an height in percentage to the element, relative to the parent. If the parent does not have any height, it doesn't work and it behaves as height: auto.

If it's a bug please provide the steps to reproduce it and maybe some code samples.
Set an height on the grid element. Call lost-waffle after (which can happen for various reasons).
Height is now overridden, either as auto (if parent height is not set) or by lost-waffle percentage (which is kind-of expected, but not in every case).
Here you can see a pen, with different scenarios of a waffle grid, with a related height issue.
NB: this is also what happens in the example page, where the waffle divs use a line-height: 100px; trick to maintain the height. The example is also slightly deceiving, since it shows an overflowing vertical grid (5/3), without parent height, which I think it is the way it was supposed to work.

What is the desired behavior?
The desired behavior would be the number 3. in the pen, that is a waffle grid with a set height for grid elements, without overflowing the parent and without last row margin.
To make this achievable without using !important or altering the source order, we could introduce a no-height parameter for lost-waffle, in order to skip the attribution of the height in %.
Example:

div {
  height: 100px;
}
[...]
section > div {
  lost-waffle: 1/3 no-height;
}

What's the motivation or use-case behind changing the behavior?
Avoiding to override height when lost-waffle is declared after. Sometimes we may use a css component library, setting an height of an element and we want to maintain the original style without redeclaring it or using !important. This could also happen in some js framework where css gets imported automatically without a specific order, or simply declaring a new LostGrid layout in a media query.
See also issue #183.

What version of LostGrid, browser and browser version are affected by this issue? Did this happen in previous versions?
All of them, as far as I know.

Anything else?
I created a pull request with a proposed solution. It follows a very simple logic, mainly copied from float-right parameter. The parameter name can be different, anything that makes sense.

Peter Ramsing · Answer 1 · Tue Jun 12 2018 10:47:16 GMT+0800 (China Standard Time)

@elgandoz, thanks for bringing this up and the PR. I was off for a bit but let me get my head around this and see if we can get something worked out. I'm excited to see what you came up with!

Peter Ramsing · Answer 2 · Tue Jun 12 2018 11:25:59 GMT+0800 (China Standard Time)

I mentioned a few of my thoughts on the PR. The PR aside, this is an interesting thought process.

I'd love to see lost-waffle be replaced by vanilla display: grid but legacy browsers is one of LostGrid's killer features.

Waffle wasn't designed to have a different height...by its nature, it's a square. Now, @corysimmons, is the original creator and may have different thoughts.

So the question for me is whether or not lost-waffle is where this belongs. I'm tempted to say that it is. It feels right.

Alternatively, I could see something like lost-grid but now we're just making fun of display: grid.

I do think that lost-waffle could support this just fine.

Cory Simmons · Answer 3 · Tue Jun 12 2018 22:03:13 GMT+0800 (China Standard Time)

Why negate height in waffle? Why not just use lost-column?

tbh I don't know the use case. Maybe it's cool.

Peter Ramsing · Answer 4 · Tue Jun 12 2018 23:29:41 GMT+0800 (China Standard Time)

There are some margin issues with lost-column in order to get the desired results. The additional CSS does feel nicer with lost-waffle but I could play around to see if lost-column could be adapted instead.

Yeah, Maybe that is what should be done. Maybe this does live on lost-column. 🤔

Of course, pending browser needs.... grid-template-columns: 1fr 1fr 1fr; 😄 CodePen

Cory Simmons · Answer 5 · Wed Jun 13 2018 04:18:17 GMT+0800 (China Standard Time)

Sorry I really don't know what's going on anymore. 😬

Marco Gandi · Answer 6 · Sat Jun 16 2018 13:51:00 GMT+0800 (China Standard Time)

Hey guys, thanks for taking the time to check this. I'll try to clarifying my idea:

Waffle use case.
lost-waffle was probably conceived as a tic-tac-toe regular grid (3x3, 4x4,...) but it's, in my experience, a rare use case. The row container it also need a height declared.
I often use the waffle to display list of photos, or news teasers, cards, or any irregular grid (3xsome).

Why not using column?
Simply because waffle deals with the gutter between rows, also removing the margin from the last one. The column doesn't add vertical gutter. Adding a vertical gutter manually will force me to write some specific selector to select the number of element of the last row, which is not ideal.

Why removing the height? In some cases, I had the need to declare the height to some particular class of the grid item (imagine something like card.short, maybe inherited from some framework). Using the waffle in this case make the item collapse it's height, because it gets overridden as height: auto.

To conclude, my thought was: adding the parameter no-height will allow to use the waffle on elements with a height declared previously.

The parameter won't chance the current behaviour, and it's a very simple implementation.

Marco Gandi · Answer 7 · Sat Jun 16 2018 14:02:10 GMT+0800 (China Standard Time)

Thanks @peterramsing for you example with grids, it's exactly what I need. But unfortunately IE support is still a deal breaker in my case (I work with many PA offices), and that's one of the main reason I use lost. Another reason is that this framework is just beautiful, effective and easy to read. Speaking of, thanks for this awesome work.

Peter Ramsing · Answer 8 · Sun Jun 17 2018 02:03:46 GMT+0800 (China Standard Time)

Daw shucks. Thank @corysimmons for the core; I'm just the gardener at this point. 😄

Okay, dream with me for a second.

/** LostGrid syntax **/
.Parent {
  lost-grid: 1/3;
}

/** Outputs **/
.Parent * {
  margin-top: 0;
  width: calc(99.9% * 1/3 - (30px - 30px * 1/3));
}

.Parent *:nth-child(1n) {
  float: left;
  margin-right: 30px;
  margin-bottom: 30px;
}

.Parent *:nth-child(3n + 1) {
  clear: both;
}

.Parent *:nth-child(3n) {
  margin-right: 0;
}

.Parent *:nth-last-child(-n + 3) {
  margin-bottom: 0;
}

.Parent::after {
  content: '';
  display: table;
  clear: both;
}

Here's an example: https://codepen.io/peterramsing/pen/aKVboq

Why this?

lost-column is for columns
lost-waffle is for waffles
lost-grid could be what this is... and could be "ejected" later if one wanted to move to CSS Grid.

Marco Gandi · Answer 9 · Sun Jun 17 2018 07:57:25 GMT+0800 (China Standard Time)

My considerations:

I like the lost-grid naming, it's more natural, simpler to understand.
I like the selector on the parent: it avoids declaring the clearfix aside and gives the idea of grid of same width elements. It breaks the common pattern of declaring lost on the child elements though.
if lost-waffle is for waffles and lost-grid is for grids... I'm not sure why declaring the height as a fraction is useful. Weren't we trying to escape that in the first place? Which means not making the assumption of a specific number of rows, or setting an height to the parent.
grid and waffle will overlap a bit, but I like the idea of being able to eject to css grid

Peter Ramsing · Answer 10 · Sun Jun 17 2018 22:06:55 GMT+0800 (China Standard Time)

@elgandoz, declaring the height was a mistake...it was overridden in the CodePen and I left it in by accident as I borrowed most of the code from lost-waffle. I've updated the CodePen and my code chunk.

So you are right, no height should be declared.

So this is a new API proposal at this point, it sounds like.