Duplicate properties removed (for env - constant)

[dorianrod]

Hi,

This code:

.cls { padding-top: 1rem; padding-top: calc(1rem + constant(safe-area-inset-top)); padding-top: calc(1rem + env(safe-area-inset-top)); }

is reduced in: .cls { padding-top: calc(1rem + env(safe-area-inset-top)); }

the problem is that I need to keep these 3 properties because it depends on the environment (some supports constant or env, or none).

Is there a way / an option to keep all these properties?

Have a good day DR

[anikethsaha]

It's a very weird use case cause anyway your browser will discard the top ones. I don't think you can opt-out from this from the preset !

cc @evilebottnawi

[alexander-akait]

It is bug, we should keep both of them because it can break code for legacy browsers

[anikethsaha]

.cls {
padding-top: 1rem;
}
.cls {
padding-top: calc(1rem + constant(safe-area-inset-top));
}
.cls {
padding-top: calc(1rem + env(safe-area-inset-top));
}

What about this then? It will inject like this right

.cls {
padding-top: 1rem;
padding-top: calc(1rem + constant(safe-area-inset-top));
padding-top: calc(1rem + env(safe-area-inset-top));
}

[alexander-akait]

Keep them all

[anikethsaha]

I think a better fix for this will be to make the discard-duplicate plugin opt-in-out like have an option in the preset to have enabled it or not cause what this plugin mostly does is to remove those duplicates. if we are keeping them all, then it won't have many operations and use case to it

[alexander-akait]

@anikethsaha it is unsafe minification, but plugin in safe preset so we should fix this unsafe case

[dorianrod]

.cls {
padding-top: 1rem;
}
.cls {
padding-top: calc(1rem + constant(safe-area-inset-top));
}
.cls {
padding-top: calc(1rem + env(safe-area-inset-top));
}

What about this then? It will inject like this right

.cls {
padding-top: 1rem;
padding-top: calc(1rem + constant(safe-area-inset-top));
padding-top: calc(1rem + env(safe-area-inset-top));
}

Yes, it works as a temporary solution. But it implies to review all the css code to be sure that the css has not been changed after minification.

[Exelenz9]

Probably, a good solution here could be using the @supports media-query:

.cls {
  padding-top: 1rem;
}

@supports (padding-top: constant(safe-area-inset-top)) {
  .cls {
    padding-top: calc(1rem + constant(safe-area-inset-top));
  }
}

@supports (padding-top: env(safe-area-inset-top)) {
  .cls {
    padding-top: calc(1rem + env(safe-area-inset-top));
  }
}

Such method worked for my case.

[yisibl]

As a developer tool, cssnano should not guess or require developers to use a certain way of writing CSS.

We should fix this bug fundamentally.

[yisibl]

In other words, CSS code that does not use @supports works in the browser, and it should still work after being compressed by cssnano.

[zhoudewei2526]

After removed postcss-merge-longhand plugin , there was no such problem

[zhoudewei2526]

add this config in your package.json

"cssnano": {
    "preset": [
      "default",
      {
        "mergeLonghand": false
      }
    ]
  }

[jameshobden]

I have experienced this today too with padding: 50px 0; padding: clamp(50px,6vw,100px) 0;. @zhoudewei2526 helped me temporarily fix it with mergeLonghand but I believe this is a fundamental oversight that should be fixed.

[ludofischer]

I believe this is a fundamental oversight that should be fixed

I have been wondering for some time if we should remove mergeLonghand and mergeRules from the default ('safe' config). It's been years they have been buggy and the situation gets worse as developers use features that were introduced after the plugins were first written. For example, when I looked at the code, I found the plugins did not consider the existence of CSS variables.

[nikashitsa]

Hey, how it's going? I have same issue.

[ludofischer]

Looking at this again, I think we can fix it without completely deactivating merge longhand.