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. :wink:

*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? :dancer:

[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 ;)

[corysimmons]

Okay, so forget lost-nth-child and instead just convert the cycle param (and rule, e.g. lost-column-cycle) to an nth-child expression?

I like this idea.

We'd need to wrap the shorthand cycle in parens. So a rule might look like lost-column: 1/2 (2n + 1);. For the longhand we could exclude the parens: lost-column-cycle: 2n +1;.

Catching that arg and using regex is what I was thinking and I can see how to implement it already, but I'm 99% sure this won't support all possible nth-child patterns out of the box... It kind of seems like we'd have to rewrite how browsers implement the nth-child selector with JS and regex. :\

[corysimmons]

And what about people who want to use nth-of-type, nth-last-child, etc., etc., etc.?

lost-column: 1/2;
lost-nth-of-type: 2n + 1;

lost-column: 1/2 (2n + 1) type;

?

If we're going to do something like this, I reeeeally think we should reconsider even offering shorthand as it's not explicit at all.

[corysimmons]

I can't remember why I added in clear: left; on https://github.com/peterramsing/lost/blob/master/lib/lost-column.js#L131-L133 but if we can get rid of it, these implementations would be easy.

I feel like there was a legit reason for it though... I just can't remember. Too bad I don't write good commit messages. :^(

Update: I remember why I added it. I wanted rows to clear each other in this weird/rare situation http://codepen.io/corysimmons/pen/zrEojp?editors=110

I think we should drop clear: left; in a major release in favor of the flexibility of using nth selectors for cycle args.

This would be super exciting and make cycle insanely more powerful.

[adrian2x]

Yeah I originally meant to include the expression inside the shorthand cycle on lost-column but you make a good point in saying

And what about people who want to use nth-of-type, nth-last-child, etc., etc., etc.?

So I agree with you that maybe dropping the shorthand would be ideal, in favor of more advanced properties that allow for more customization. More explicit, more readable, and more powerful. :+1:

[peterramsing]

Sorry to be so out of the loop on this. Got sick and am just cracking the laptop today. This conversation is awesome, though.

@corysimmons Already said it, but to second the motion that there are other nth-* properties. Even PR #216 from @zgreen regarding this.

@adrianca You made a great point about there being super users and users that want something that just works out of the box.

I think that these properties should be broken out of the shorthand. I'm an advocate for more verbose code (within reason) that self-documents. Especially these days with auto-complete.

[adrian2x]

@peterramsing agreed! Also another question, what about space-around and space-between flex alignment? It looks like right now those are not supported?

[peterramsing]

Another needed feature/enhancement for sure.

[adrian2x]

@peterramsing Just wanted to confirm that it wasn't implemented yet. I'm taking a crack at it.

[peterramsing]

@adrianca Code machine. I really need to get some more roadmap/7.0.0 definition done soon!

[peterramsing]

@adrianca That being said–I want to make sure that we don't bite off more than we can chew with 7.0.0. I think that the more features the merrier, but do you have any gut feelings that this should wait till later? Maybe we do make 7.0.0 a huge release with all these features.

[adrian2x]

@peterramsing It's done now. I added it to PR 241. This should enable for all possible flex box-based alignment and combinations, so I believe this property should be pretty much done?