Simple grid layout

[adrian2x]

@corysimmons @peterramsing Wondering how I can achieve the following layout using lost:

+------------------------------------------------+
|                   Container                    |
|+----------------------------------------------+|
||                      1                       ||
|+----------------------------------------------+|
|+----------------------++----------------------+|
||          2           ||           3          ||
|+----------------------++----------------------+|
|+----------------------++----------------------+|
||          4           ||           5          ||
|+----------------------++----------------------+|
+------------------------------------------------+ 

I have some markup that sets the container element, and 1 has lost-column: 1, and each of 2, 3, 4 and 5 have lost-column: 1/2 but they show up on top of each other because of the margin-right. Is there any property that I can use to tell lost that I want no margin-right after 3 and 5, so that they show up on the same row?
Thanks!

[corysimmons]

There's no Lost property for that yet. We could probably make one with some nth-child hackery. Like lost-column: 1/2; lost-cycle-after: 1; but I wonder how far Lost's scope should go? This has came up a couple times so it might be worth talking about.

In the meantime, if you only need 3 elements in there, you can do this: http://codepen.io/corysimmons/pen/MKvNBY?editors=110

Here's what the CSS would look like if lost-cycle-after existed: http://codepen.io/corysimmons/pen/EPvqdN?editors=110

We should probably implement this even if it makes Lost a bit more complex. It adds a solution to an question and I'm not aware of any other grid that attempts to solve this problem.

The code would need to work for any property cycle was a part of.

[corysimmons]

^ I may have gone a bit crazy with the labels. :X

[peterramsing]

@corysimmons I think you might be looking for the component: lost-core label. 😉

*edit: now that I'm thinking about it, all those labels are accurate and lost-core isn't really. Maybe we need a lost-lots label? 💃

[adrian2x]

So after playing with your example, I can see that by tweaking cycle I can tweak margins in between the elements. That is a great concept!

Now, let's say I do lost-column: 6/12 2. This would result in something like

:nth-child(2n) { 
    margin-right: 0; 
}

but I have no control over the b parameter in the an + b expression of the :nth-child selector, because cycle controls only the n param.

I think that if cycle accepted a whole expression instead of an integer, that could be passed into :nth-child(...) and then it would allow for more advanced fine-tuning. How do you feel about this @peterramsing and @corysimmons?

[corysimmons]

@Adrianca That's the general concept but the nth-child selector is confusing in practice. Which makes more sense at first glance?

.full {
  display: block;
}
.half {
  lost-column: 1/2;
  lost-nth-child: 2n + 1;
}

or

.full {
  display: block;
}
.half {
  lost-column: 1/2;
  lost-cycle-after: 1;
}

That said, lost-nth-child would be infinitely more flexible than lost-cycle-after (and slightly harder to implement but still possible I think).

[adrian2x]

So the way Im thinking about it, is that cycle is a pretty advanced concept. Like, for power users. Most beginners coming to lost are probably going to want an easy grid out of the box, ready to go. But for those who are going to want to use cycle to customize their grids, is going to make more sense to explain it in terms of
"This feature allows you to control the margin on the nth-child of the container and you just put whatever you want to go into the child selector as the value."
than as some feature that allows you to customize the margin on the value that matches the b value of the an + b expression inside the nth-child selector of the parent container.

Moreover, like you said yourself a lost-nth-child would be really more flexible than lost-cycle-after, and you could get more done with it than with after. So if this is going to be a new feature altogether (since lost-cycle-after doesn't yet exist anyway) I'd rather go for maximizing flexibility with the smallest surface area, the unix way.

This is some feedback that I'm offering from a user's point of view, but it might just be a matter of taste though.

[adrian2x]

The difficulty regarding implementation would be parsing the value expressions, but it shouldn't be too much of a big deal with some regex magic ;)