Layout gap value list support

[lievenjanssen]

Some additional improvements we could do:

• Support $increment in the gap mixins (e.g. gap-class-selectors($from: 4, $to: 24, $increment: 4, $gapUnits: px em rem, $includeSelectorsForMediaSizes: false) but that would be a breaking change.
• Add flex-row-properties to elements that don't have fx-layout and have fx-gap*, like we do for fx-flex:

  css-fx-layout/src/lib/flex-classes.scss

  Lines 13 to 15 in c0b3b02

  	*:has(>.fx-flex,>.fx-flex-grow):not([class*="fx-layout-"]) {
  	@include flex-row-properties;
  	}

  We could also do this for fx-align*.

What do you think?

[philmtd]

Thank you very much for your contribution.

Support $increment in the gap mixins (e.g. gap-class-selectors($from: 4, $to: 24, $increment: 4, $gapUnits: px em rem, $includeSelectorsForMediaSizes: false) but that would be a breaking change.

Couldn't we add $increment as the last parameter with a default value of 1 in the "$from-$to"-mixin? That way we would not implement a breaking change, right?

Regarding my second comment: What do you think about using separate mixins? One for "$from-$to" and another for a fixed list of values?

Add flex-row-properties to elements that don't have fx-layout and have fx-gap*, like we do for fx-flex

We could also do this for fx-align*.

Sure, feel free to add that :)

[lievenjanssen]

Couldn't we add $increment as the last parameter with a default value of 1 in the "$from-$to"-mixin? That way we would not implement a breaking change, right?

I feel that logically $increment should be a parameter before $includeSelectorsForMediaSizes but I agree we could add it as the last parameter so we don't need to introduce a breaking change. Will also move $increment parameter to the last position in the flex size mixins.

[lievenjanssen]

I'll also add the automatic row layout for layout gap and layout align classes and attributes.

[philmtd]

Couldn't we add $increment as the last parameter with a default value of 1 in the "$from-$to"-mixin? That way we would not implement a breaking change, right?

I feel that logically $increment should be a parameter before $includeSelectorsForMediaSizes but I agree we could add it as the last parameter so we don't need to introduce a breaking change. Will also move $increment parameter to the last position in the flex size mixins.

Yes, the logical order of the parameters is not the best then. An alternative would be to add another mixin.. but I think this may overcomplicate the API. :/

[lievenjanssen]

Couldn't we add $increment as the last parameter with a default value of 1 in the "$from-$to"-mixin? That way we would not implement a breaking change, right?
I feel that logically $increment should be a parameter before $includeSelectorsForMediaSizes but I agree we could add it as the last parameter so we don't need to introduce a breaking change. Will also move $increment parameter to the last position in the flex size mixins.

Yes, the logical order of the parameters is not the best then. An alternative would be to add another mixin.. but I think this may overcomplicate the API. :/

Maybe we should introduce a breaking change? I think having the ability to increment the gaps makes total sense.

[philmtd]

Maybe we should introduce a breaking change? I think having the ability to increment the gaps makes total sense.

I guess we're in the lucky situation that this library is not that popular (yet?), so we would not break many dependent projects. So yes, I'd be open to introduce this as a breaking change. I mean.. I could just release it as a new major version to make things obvious. Or just leave it as the next minor because it does not affect too many projects. What are your thoughts on it?

To make sure the mixins are invoked with correct argument types, do you think we could/should add type assertions? I'm not familiar with the best practices in SCSS but I was thinking about something similar to this in the mixin:

@if (type-of($to) != "number") {
    @error("$to should be a number");
}

[lievenjanssen]

I guess we're in the lucky situation that this library is not that popular (yet?), so we would not break many dependent projects. So yes, I'd be open to introduce this as a breaking change. I mean.. I could just release it as a new major version to make things obvious. Or just leave it as the next minor because it does not affect too many projects. What are your thoughts on it?

If it's a breaking change I would definitely go for a new major version. There's going to be quite some changes in it when we also include the flex-size changes so a new major version makes sense.

[lievenjanssen]

To make sure the mixins are invoked with correct argument types, do you think we could/should add type assertions?

Not sure if it's really needed. I think it's quite obvious. I added a check for $increment for flex-sizes though (will still open the PR later today) since both $from and $to need to be dividable by $increment in order to make the logic work.

[lievenjanssen]

For me this can be merged now.

I'll open separate PR's for the increment change and automatic row layout for layout gap and layout align classes and attributes.