feat(minify): avoid removing the default value of the filter function

[yisibl]

There are several inconsistencies in Chrome's implementation of defaults in older versions, which can cause filters to behave in opposite ways in older browsers. Perhaps other browsers have similar bugs with inconsistent defaults between old and new versions, I didn't continue searching.

In older versions of Chrome(49), -webkit-filter: brightness() also caused crashes.

Input

.foo {
  filter: brightness(1);
}

Output

.foo {
  -webkit-filter: brightness(); /* I'm also concerned that `-webkit-filter` does not support omitting the default values. */
  filter: brightness(); /* In older versions of Chrome, the calculated value is 0 */
}

• https://bugs.chromium.org/p/chromium/issues/detail?id=964696#c13
• https://bugs.chromium.org/p/chromium/issues/detail?id=798683#c6

I would recommend turning off arguments omitting of the functions in the filter by default, it's not worth sacrificing correctness for those few bytes.

Fixed: #251

[yisibl]

@devongovett PTAL

[devongovett]

Chrome 49 is almost 10 years old so I doubt anyone is targeting that anymore. But we could potentially check the targets and see if the minimum version is below that.

[yisibl]

@devongovett Beyond the issue with -webkit prefix functions, the default value for brightness() also varies between older and newer versions of Chrome. Currently, this lacks MDN data.

.foo {
  -webkit-filter: brightness(); /* I'm also concerned that `-webkit-filter` does not support omitting the default values. */
  filter: brightness(); /* In older versions of Chrome, the calculated value is 0 */
}

When CSS authors explicitly write brightness(1), it's likely to circumvent browser bugs—and LightningCSS has brought that bug back. If this is meant to fix a live bug, it's incredibly frustrating.

So, I still stand by my view: we really shouldn't obsess over reducing byte counts. Maintaining CSS correctness is far more important.