Add global configuration and methods to enable the use of calc by default in numeric operations

[SalimBensiali]

Looking at

bootstrap/scss/_variables.scss

Line 925 in 72d3b6e

$input-height-inner: add($input-line-height * 1em, $input-padding-y * 2) !default;

while add is using calc by default (See https://github.com/twbs/bootstrap/blob/main/scss/_functions.scss#L222), if $input-padding-y is overridden to use calc (say calc(2 * 14px)), then the entire assignment will fail with an error such as

Undefined operation "calc(2 * 14px) * 2".

because the outer multiplication by 2 is not using calc itself.

Could we add a global and overridable SCSS variable ($return-calc) and introduce a multiply function that would use that variable to decide whether to return calc or not? The existing add could also benefit from that global $return-calc variable.

The original assignment would then turn change to the below and would no longer fail.

add(multiply($input-line-height, 1em), multiply($input-padding-y, 2)) !default;

I would be happy to supply a PR for this if you see value in it.

Cheers

[SalimBensiali]

Thanks @julien-deramond for labelling this issue. This got me thinking. the way the CSS is currently written for example negative margins (See

bootstrap/scss/forms/_form-control.scss

Line 170 in 7ff271b

margin: (-$input-padding-y-lg) (-$input-padding-x-lg);

), means that if a user overrides variables to use calc, the compilation will also fail. Is this a known limitation and is there a plan to make bootstrap Sass variable overrides support calc?

[julien-deramond]

Is this a known limitation and is there a plan to make bootstrap Sass variable overrides support calc?

This is a known limitation, though perhaps not specifically for this use case. There are various constraints related to different calculations (calc, add, etc.), negative values, and the overrides for both Sass and CSS variables with different values or units. The construction of components can vary significantly based on when they were initially built and how they evolved with user feedback.

Addressing these issues comprehensively is challenging. However, we hope to undertake some refactoring in this area for the v6 release. While it might be possible to address parts of this in v5, it would likely be limited to specific components and done cautiously to avoid regressions, which can be quite tricky.

Although I haven't tested it, one potential approach could be using Sass unit testing. By modifying each Sass variable (and/or CSS variable) and compiling the components in different configurations, we could maybe at least verify if the code compiles correctly.