1. When .o-layout--reverse is combined with .o-layout--left, the ruleset must declare justify-content: flex-end; since the main axis direction is reversed (flex-direction: row-reverse;). The same is true for .o-layout--reverse.o-layout--right for which the ruleset must declare justify-content: flex-start;.
2. Where did .o-layout--stretch go?

@LayZeeDK

1. I will fix it, thank you.
2. I remove it because.o-layout__item are stretch by default. And I was thinking that it isn't the place to define o-layout__item child behavior (side effect) (but I can be wrong).

(2) When you removed .o-layout-stretch, you removed a ruleset:

.o-layout--stretch > .o-layout__item {
  display: flex;
}

So the flex items used to have display: flex; themselves which stretched their direct children—the content—like seen here:

From this sample markup;

<div class="[ o-layout o-layout--stretch ]">
    <div class="o-layout__item  u-1/3">
        <p>
            Foo
            <br>
            Bar
            <br>
            Baz
        </p>
    </div>

    <div class="o-layout__item  u-1/3">
        <p>
            Bar
        </p>
    </div>
</div>

@LayZeeDK that's right and instead I think adding flexbox utilities can be beneficial.

In the two demo o-layout children have the same height so I don't think it's a job for layout object, you know?

<div class="o-layout">
    <div class="o-layout__item u-1/3 u-flex">
        <p>
            Foo
            <br>
            Bar
            <br>
            Baz
        </p>
    </div>
    <div class="o-layout__item u-1/3 u-flex">
        <p>
            Bar
        </p>
    </div>
</div>

In this example, I think that when <p> start your aren't in a layout issue. Furthermore with display: flex you can have some side effect like width... So I prefer to solved that in another component/object or using some utilities.

PS : o-layout__item are not needed anymore.

This is great... some examples of simple grid layouts and markup examples to experiment with (maybe on codepen) would be great. 👍

What about considering an option between using a traditional grid with inline-block and a flex grid. I'm pretty sure I saw a discussion somewhere that inuitcss was confident of their grid and had no intention to swapping to flexbox. Perhaps an option to choose between the two would be best.

Also I think utilities.width would have to set the width of flex items differently. Missing max-width and flex: 0 0 (width) property (i think)

@xavianaxw I think we can move to flexbox and keep code simple, widths utilities will works same as v6...

I'm pretty sure I saw a discussion somewhere that inuitcss was confident of their grid and had no intention to swapping to flexbox. Perhaps an option to choose between the two would be best.

It was in a pretty old issue, before the decision to stop supporting old browsers in v7. The original grid works great and was backwards compatible, but without that requirement flexbox is just a simpler, better solution.

Ah right. I'm all in for flexbox anyway!

I think @LayZeeDK had a good argument by pointing out the missing stretch modifier. I think this should be part of the layout object via the currently available --stretch modifier, which means that it shouldn’t stretch by default.

I’m not a fan at all of achieving this behaviour with an additional .u-flex utility on the layout item. Rather this all speaks for keeping the .o-layout__item classes on the children, IMO.

<div class="o-layout">
    <div class="o-layout__item  u-1/2">
        ...
    </div>
    <div class="o-layout__item  u-1/2">
        ...
    </div>
</div>

If I want the items to align in their height no matter what, I want this to determine on the BEM block, i.e. .o-layout, hence assigning the additional .o-layout--stretch class:

<div class="o-layout  o-layout--stretch">
    <div class="o-layout__item  u-1/2">
        ...
    </div>
    <div class="o-layout__item  u-1/2">
        ...
    </div>
</div>

I don’t want to mess with adding some utility classes on each item, because to me, this is the job of the layout object—modifying how elements of the object behave.

I agree with @csshugs. Overall I don't really like to use utilities apart from what is indispensable, and if you wanna modify the behavior of all children uniformly, a modifier is the right approach.