Omit units for zero values

[krisbulman]

This was incorrectly posted in the Compass queue, re-posting here on behalf of @nschonni as I see value in unit omission for zero values.

A zero value in CSS is the same no matter the units.
This could improve the resulting stylesheet size.

https://github.com/stubbornella/csslint/wiki/Disallow-units-for-zero-values

[Anahkiasen]

+1 for that, would look cleaner also.

[robwierzbowski]

When would the unit be stripped? For math in mixins and functions a zero with units is sometimes necessary.

[Anahkiasen]

In what case does the unit of a zero matter in a multiplication/addition/else ?

[Snugug]

Just to slightly correct the premise of this suggestion, it's actually incorrect to say that zero absolutely doesn't need units inside CSS. For instance, resolution media queries require units even if the value is zero.
As for mixins and functions, the unit of the zero may not be required for the output, but it may be required to ensure you're working with like units even if the result of equation is zero (for instance, adding 1em or 16px).

On Feb 17, 2013, at 11:40 AM, Maxime Fabre notifications@github.com wrote:

In what case does the unit of a zero matter in a multiplication/addition/else ?

—
Reply to this email directly or view it on GitHub.

[robwierzbowski]

As snugug says, 10em - 10em + 2px shouldn't work. For an example in wide use, the unit removal trick

$var / ($var * 0) +1 

depends on zero with a unit.

[Anahkiasen]

Yeah but as I understood it the initial proposal was to remove units from the final CSS, not in the middle of the SASS calculus.

[nschonni]

The idea was for the end CSS, so maybe adding it to the list of optimizations in the output style. Similar to how the :compressed will optimize properties to their smallest form.

[robwierzbowski]

I thought that was probably the idea, just wanted clarification.

[Snugug]

That's fine as long as its understood that not all of CSS is cool with unit less 0s now and potentially in the future. I'd be curious how much is actually saved by this pseudo-optimization especially when you can currently just write 0 w/o units. (i.e. how often is a 0 with a unit generated that you would want it stripped out)

On Feb 17, 2013, at 1:52 PM, Rob Wierzbowski notifications@github.com wrote:

I thought that was probably the idea, just wanted clarification. +1.

—
Reply to this email directly or view it on GitHub.

[nex3]

Sass doesn't have enough context information when rendering a number to a string to determine if it's safe to leave off the unit.

[chriseppstein]

I verified with @tabatkins that it is safe for Sass to omit the unit for lengths when the value is 0. This is true for all properties. However, there is one known ambiguity if you have a list of values for the flex property without specifying all the values because it mixes two <number>s and a <length>, and so in some cases you either need a unit specifier or need to follow a particular order.

We should consider adding support for this. Re-opening.

[nex3]

I'm very skeptical of any behavior here that relies on knowledge of CSS's current ambiguities between numbers and lengths. I don't want to have to maintain a list of workarounds for properties like flex.

There are some types of optimizations that are better for a post-processor with encyclopedic knowledge of CSS properties to do, and I think this may be one of them.

[judowalker]

I created a minimal working example which demonstrates that omitting the unit for lengths when the value is 0 can affect how the content is displayed. This happens across browsers:
https://codepen.io/judowalker/pen/xrMxWj

[tabatkins]

% is not a unit, and never generates a <length>; omitting it flips you into <length> territory (implying 0px or the equivalent), which can definitely be a behavior change in some circumstances.

[judowalker]

@tabatkins yes technically you are right but it's still relevant in this discussion and according to https://github.com/CSSLint/csslint/wiki/Disallow-units-for-zero-values, "the value of 0 works without specifying units in all situations where numbers with length units or percentages are allowed," which isn't true for percentages.

[tabatkins]

Ah, that CSSLint line is wrong, then.

[judowalker]

@tabatkins and the CSSLint warning that's generated as well. :P

[nex3]

I'm moving this issue to the new Ruby Sass repository because it's specific to Ruby Sass's implementation. Once it's there, I'm going to close it as "on ice" because Ruby Sass is deprecated and no additional features are planned for it.

[mkasprz]

I discovered that there apparently is a difference between 0 with and without a unit. It's connected with the transition property. At least in some cases (like line-height property) an animation will not be played if there's 0 without any unit. I made a Pen to illustrate it: https://codepen.io/anon/pen/pqyjBd?editors=1100 .
I believe it may be a bug, but I experienced the same behavior in both Chromium and Firefox.

I assume there should be kind of a setting to disable removing units for 0s.

[nex3]

@mkasprz Good catch. Since we aren't aware which property a number is being serialized for, we shouldn't remove units ever.

[arthurio]

Another bug I found...

right: max(0px, calc((100vw - 1600px)/2)) will convert to right: max(0, (100vw - 1600px)/2) which is invalid.

• ❌
• ✅

Is there a way to tell sass not to perform this optimization?

[nex3]

@arthurio When I compile that example with Dart Sass 1.44.0 I get max(0px, (100vw - 1600px) / 2). I suspect you have another tool in your pipeline which is incorrectly removing the units.

[arthurio]

@nex3 Good to know, I'll do some digging and report back. Thanks for letting me know 👍🏻

[arthurio]

@nex3 Sorry I forgot to report back, the issue was indeed further down the pipeline... Our minifier is the one which was replacing 0px with 0.