html-next / flexi

Just a layout framework. Design for cross-platform with ease.
https://flexi.readme.io/docs
MIT License
219 stars 36 forks source link

Discussion: manipulating flex-basis/height/width on container #45

Open yankeeinlondon opened 8 years ago

yankeeinlondon commented 8 years ago

Stemming from this slack conversation:

https://embercommunity.slack.com/archives/e-flexi/p1459540198000492

It was decided further discussion was appropriate. The discussion revolves around the ability to exercise precise height or width on a flex item within a horizontal or vertical flexbox group. The "flex" version of this would be to use the flex-basis property but Chris has pointed out that Safari has a bug when using "%" values (in my tests though fixed px/rem/em values work fine).

It may be that the more traditional form of adding height/width style properties is better supported but in either case the goal is to be able to build something like this:

image

In this case we want even spacing between components but in the one case (aka, the green one) we want to precisely state the size/height of the container.

yankeeinlondon commented 8 years ago

The ideal would be to have a compact syntax to effect this more precise control over height / width (depending on direction of the flex container). Something like the following would make sense to me:

<container fit basis="2 em"></container>
yankeeinlondon commented 8 years ago

I think the API should use "basis" as it is the "official" flexbox nomenclature but if it turns out that some combination of height/width (and the min/max variants) is better supported than flexi could transform this to these instead of flex-basis (at least until the browsers get their act together). In either case, though it will require a "build-time" transform to an inline style (classes won't work because the nature of this problem is inherently non-ordinal).

note: flex-basis feel more appropriate if it can be supported as it leverages the context of the parent's direction (aka, row/column) whereas using height/width properties requires duplicative context (and opens up mistakes on directionality that could confuse users).

runspired commented 8 years ago

@ksnyde I've mulled this over for a while, and I really love the idea of converting basis to the correct unit based on whether the layout is horizontal or vertical. It gets tricky because basis is able to change and is set by a parent element :/

It gets tricker because much of what you'd want here probably needs to change dynamically at runtime.

Consider this simple potential API which would only work if flex direction does not change and breakpoints aren't considered.

<!-- declared -->
<box>
  <box basis="2em"></box>
</box>

<!-- compiled -->
<box class="flexi-vertical">
  <box class="fl-basis-2em"></box>
</box>

<!-- generated CSS -->
.flexi-vertical > .fl-basis-2em {
  height: 2em; 
}
.flexi-horizontal > .fl-basis-2em {
  width: 2em; 
}

If this was all we allowed, this could be made to work. But what happens when...

<!-- declared -->
<box xs="vertical" sm="horizontal">
  <box basis="2em"></box>
</box>

<!-- compiled -->
<box class="flexi-xs-vertical flexi-sm-horizontal">
  <box class="fl-basis-2em"></box>
</box>

<!-- generated (broken) CSS -->
.flexi-vertical > .fl-basis-2em {
  height: 2em; 
}
.flexi-horizontal > .fl-basis-2em {
  width: 2em; 
}

Here, we are now in a situation in which we MUST either track the parent (difficult, it's not always the immediate parent, and even when it is other expressions (like {{#each}}) could be in the way), or generate all potential parent combinations for fl-basis-2em.

The situation only gets worse as you consider alternative such as:

<box vb="2em" hb="3em"></box>
<box xs="basis:2em" sm="basis:3em"></box>
<box xs="vb:2em hb:3em" sm="vb:3em hb:5em"></box>

If we ditch the ability to use % for basis, this problem becomes significantly easier, as I believe we can legitimately rely on flex-basis to simply do it's thing: https://developer.mozilla.org/en-US/docs/Web/CSS/flex-basis

yankeeinlondon commented 8 years ago

Imagine if life were actually as simple as you first imagined it. We'd be productive but it sure would be dull. 😆

yankeeinlondon commented 8 years ago

My hunch is that "non-percentage" use of flex-basis outways percentage usage. That would push me toward the value being high and the compromise being fair. My hunch is quite unscientific of course but a well stated/documented limitation is still a feature that folks didn't have before.

yankeeinlondon commented 8 years ago

Also flexi does provide -- in effect -- percentage flex-basis's for "common percentages" (aka, divisors of 12 or whatever your responsive grid is setup by).

<box xs="4 horizontal" sm="4 vertical" fit>

This is effectively a fixed width/height of 25%:

flex-direction: <responsive>;
flex: 0 0 25%;

No I can't have a fixed width of a non-standard % but considering how much complicated that is I think the compromise more than meets the much over-used "80/20 rule".

kybishop commented 7 years ago

@ksnyde The Slack discussion linked in the issue has been purged, and I'm having trouble parsing what the desired feature is. Would you mind a summary of the feature, as well as the usage pattern(s) it enables?