Proposals for improving shorthand syntax and disabling additional styles

[adamdport]

I find myself constantly frustrated and surprised by this layout API. I wanted to start a conversation as to what I'm expecting vs what actually happens.

Shorthand syntax

The shorthand flex: 1; in CSS applies the flex-grow: 1; styling. The shorthand syntax for this API, however is fxFlex="<basis>". This is counter-intuitive.

I like that fxFlex alone applies flex: 1 1 0.000000001px, but imho fxFlex="2" should yield flex: 2 1 0.000000001px.

A compromise could be that if units are used (ie. fxFlex="100px" instead of fxFlex="100", then the shorthand affects flex-basis instead of flex-grow, but personally I don't find myself ever wanting to use shorthand to affect flex-basis.

Additional fxFlex Stylings

The shorthand flex: 1 1 200px in CSS implies flex-grow: 1; flex-shrink: 1; flex-basis: 200px;. The general form fxFlex="1 1 200px" however, adds max-width: 200px; min-width: 200px;. This is counter-intuitive (and unusable in all of my use cases thus far).

I'm sure you added this for a reason, but could I we have the ability to disable these additional fxFlex stylings via config or something?

---

I love the concept of this API but feel that it's trying to do too much for me. Thanks for your consideration!

[greenGoby]

This same issue just wasted a bunch of my time today. I was sitting here struggling with why fxFlex="1 1 120px" wasn't behaving the same as flex css attribute. It was then I stumbled upon this min-width and max-width additions, which I have to agree are very counter intuitive. In fact, I am being forced to write the flex css by hand to get around this. Would love to see a fix or a way to work around this.

[ThomasBurleson]

We are discussing and attempting to address this issue before Beta.13 (in December).

[CaerusKaru]

Alright, here's what I have in mind for this (totally open to discussion):

• convert fxFlex to modify flex-grow instead of flex-basis
• introduce a new fxBasis to modify flex-basis exclusively, since supporting two behaviors on one directive seems counterintuitive
• possibly add an injection token FLEX_BASIS_COMPAT that maintains the old behavior for those who don't want to screw up their templates. This could be removed in a subsequent release. An alternative would be to have this token opt-in to the new behavior
• add an injection token FLEX_WIDTH that when set to true will add the width parameters to CSS, and won't otherwise (we could also add a compatibility token for this in the event that it represents too much of a breaking change – possibly bundled with the basis token)

Would this be satisfactory?

[adamdport]

Yes! For the last two bullets I like the injection token idea. This would permit support the old style syntax for a few releases to give people time to refactor. That being said, what was the original purpose of the max-width min-width thing? Is it safe to deprecate that behavior and remove it in a future release?

convert fxFlex to modify flex-grow instead of flex-basis

Just to be 100% clear, flex-shrink and flex-basis SHOULD have the correct defaults set (ie. 1 and 0% respectively) to satisfy flexbug #6. I'm not sure why this implementation uses the 0.0001px thing instead of 0%, either way is fine with me.

Thanks!

[ThomasBurleson]

@adamdport - many of the weird outputs for flex-basis and max-width originated as part of efforts to resolve browser-bugs and issues.

@CaerusKaru - the fxFlex supports many usages: single value (<basis>), full value set (<grow ), and calc()` values. I am loathe to introduce a new fxBasis API.

• I do like the idea of an injection token for backwards compatibility.
• I think a configuration API may be explored to configure specific runtime outputs.

[CaerusKaru]

@ThomasBurleson Sounds good. I meant more that we shouldn't/couldn't support two defaults on fxFlex, hence the added directive, but I see your point that it's just adding more complexity.

So then, the idea would be to change fxFlex to maintain its current form (with other fixes for other issues), so that by default it affects flex-grow instead of flex-basis, where users can still modify both in the full form. Then we add a compat token so that the old behavior is preserved for those who want it.

We can discuss more offline, but that looks pretty solid to me.

[adamdport]

If fxFlex is changed to affect flex-grow by default, we don't really need the existing fxGrow anymore. For consistency I think a fxBasis could replace it. Not sure why fxGrow and fxShrink were ok but fxBasis isn't?