remove zero units

[tomhodgins]

.remove-zero-unit {
  max-height: 0%;
  height: 0%;
  font-size: calc(0%);
  transform: rotateZ(0deg);
}

correct minification

.remove-zero-unit{max-height:0;height:0;font-size:0;transform:rotateZ(0)}

• removes % and deg units where they can be safely eliminated

CSSnano output

.remove-zero-unit{max-height:0%;height:0%;font-size:0%;transform:rotate(0deg)}

• should it be rotateZ(0) instead of rotate()? what if another rule has roatateY() set?
• can remove unit from % on height and max-height properties
• can remove deg from 0deg
• can remove % if final simplification from calc is 0%

[ben-eb]

• rotateZ(0) is invalid, as a unitless zero is a <length> value and not an <angle> value. https://developer.mozilla.org/en-US/docs/Web/CSS/angle
• max-height & height behave differently with a %, see https://github.com/ben-eb/css-minifier-tests/tree/master/tests/111-keepZeroPercentHeight
• calc might be correct, will have to investigate this further.

[ben-eb]

calc is complex, it depends on the property and the DOM. 0 is considered as a <length> value and not a <percentage> value, so by removing the % you are actually changing the type of the value.

For more information, see: #229

[davidhund]

Hi @ben-eb — I think I just stumbled on a related issue.

I removed postcss-calc as a postcss-cli plugin because I'm already using cssnano

Given the following CSS…

:root { --wi-gutter: 1rem; };
.test { margin: calc(-.5 * var(--wi-gutter)); }

…I noticed cssnano keeps leading zero's. I think they are safe to remove?

With postcss-calc@5.3.1:

.test{margin:-.5rem}

With cssnano@3.10.0 (postcss-calc@5.2.0):

.test{margin:-0.5rem}

Is this expected behaviour or a postcss-calc or cssnano issue?

[ben-eb]

Hi @davidhund,

I guess keeping postcss-calc in the plugins list means that it gets run twice, and so on the second pass the leading zero is stripped out? Unfortunately the way that cssnano works right now is that the values are normalised before postcss-calc runs, but I can't change the order otherwise I have other test cases that are failing.

In the meantime I've added this as a pending test case so that I can look to fixing it in a future major release. 48316a4

[davidhund]

Hi @ben-eb,

Thanks for the quick reply. Good point re: running twice! 😉

I understand why you can't simply change the order. It's not a huge issue.
Great that you've added a test already.

One thing I (naively) though of: what about always re-running postcss-convert-values (after postcss-calc)? That would have some perf overhead, but would pick up this issue, no?

[ben-eb]

Yeah, this is a possibility but not with the current architecture as duplicate plugins are filtered out. I think it's better to revisit this when I'm doing 4.0. 😄