Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
yankeeinlondon opened this issue Apr 1, 2016 · 7 comments
Open

Comments

@yankeeinlondon
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Collaborator

@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
Copy link
Contributor Author

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

@yankeeinlondon
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Collaborator

@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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants