Please add some more classes — …

[mpa3b]

.grid .unit.first { padding-left: 20px; }

.grid .unit.last { padding-right: 20px; }

.grid .single.unit { padding-left: 20px; padding-right: 20px; width: 100%; }

[cobyism]

Thanks for the issue, however I believe all of this functionality you’re suggesting already exists.

.grid .unit.first {
  padding-left: 20px;
}
.grid .unit.last {
  padding-right: 20px;
}

These two rules are already implemented by these two lines. I designed it this way because it sucks to have to have extra class names in the DOM for things that can be inferred. By leaving the class names off, and relying on :first-child and :last-child pseudo selectors, you can safely reorder the .units inside your grids without having to rewrite which ones have .first and .last applied each time you make a change.

.grid .single.unit {
  padding-left: 20px;
  padding-right: 20px;
  width: 100%;
}

The left and right padding on this one also gets implemented using the above pseudo selectors. Any .unit that is both a :first-child and a :last-child will have both rules applied, giving it the appropriate padding. As for the 100% width, that’s also unnecessary, as single .units (without a specific width like .whole applied) start off as 100% width because of this line here.

If I’ve misunderstood what you’re suggesting, let me know. :+1:

[mpa3b]

You are right, but what if I need to render a table-like grid from an array?

[cobyism]

@mpa3b gridism should be completely independent of the server-side rendering technology used, and relying on the first/last-child pseudo selectors actually means that don’t have to worry about any server-side logic to conditionally output .first and .last classes into the DOM either. Can you give me an example of the problem you’re running into?

[mpa3b]

simple: a block with elements 7 items in 3-item grid. [] [] [] ← :last doesn't work [] [] [] ← :first doesn't work either [] ← :last works.

For example: I use a CMS, Bitrix or Dupal.

In Bitrix I have a component wich renders its template. The component has a PHP-array as data source, so I render it to HTML using cycles like foreach(); So I have a container tag and a number of items in it. I can separate them with additional markup to use .grid container class, but the semantics will change.

[cobyism]

Ah, I see what you mean. This is partially a result of poor documentation on my part: The .grid container is only really designed to be used as a single "row", not as a single generic container for a potentially large number of rows. In this sense, this project (currently) takes the approach that it’s up to the person using it to know how many units are going to be in each row, and to open up a new .grid container for each for of .units. If using a CMS for example, you’d use the server-side logic to work out if the current array index is 0 when taken modulo 3 (if using thirds for .units), and then output a separate .grid for each group of three.

You’re not the only person who has suffered from my lack of communication about this, so it’s definitely on my radar to improve.

There are ways around this with CSS alone, but it’s not trivial to implement a comprehensive solution. For example, it might be possible to rework the code to instead use the .one-third:nth-child(3n+1) pseudo-class functionality (for all the possible widths) to automatically add the right padding to the correctly numbered children, however this gets really complex when all of the children aren’t even widths. For example, the inclusion of a .two-thirds class would throw out any subsequent .one-third:nth-child(3n+1) units, since they’d all now be offset by an extra unit than expected.

For now, the solution is to use server-side logic to ensure each .grid contains no more .units than make up a full-width "row". I’m sorry I don’t have a better answer for you, but hopefully at least knowing what’s up will help you work out a solution. If you have any ideas for how to approach a solution that uses CSS alone, I’d absolutely :sparkling_heart: to hear them!

[mpa3b]

Thank you for your answer. Now I see — Gridism was ment to markup the general teplate layout, right? That was my ideal to extend it to use it in minor template objects. Well, my addition of classes .first, .last and .single actually solves my problem for me, I just wanted to share my solution.

Thanks again for your wonderfull framework..

[cobyism]

Gridism was ment to markup the general teplate layout, right? That was my ideal to extend it to use it in minor template objects.

Gridism can handle nested grids alright too, for sub-components of a larger grid, but in either case you just need to never have more than a 100% width worth of .units inside any horizontal .grid row, or you’ll run into problems like you’ve explained.