[Proposal] Remove legacy monkey-patch functions

[matthew-dean]

Earlier versions of Less offered support for CSS functions that weren't yet supported cross-browser, acting as a de facto Babel-esque (although pre-Babel) polyfill for future CSS syntax.

However:

1. Many of these functions are no longer needed, such as the poly-filled color functions. See: https://caniuse.com/#feat=css3-colors
2. These monkey-patched functions are now failing at newer features added to CSS, such as custom property values. See: Custom properties inside builtin functions like rgba() throw error #2986

Functions that still act as polyfills (don't have cross-browser support) should be discussed, but IMO well-supported functions should stop being polyfilled, and future Less versions should probably not try to polyfill CSS functions.

[seven-phases-max]

It depends on what you mean with "polyfilled". Note for example the built-in rgba is not really a polyfill simply because of something like darken(rgba(1, 2, 3, .4), 5%) <- here it must be evaluated as a Less function that accepts some args (numbers in a simple case) and returns a built-in color object for a further manipulation.

After all also note foo: rgba(1, 2, 3, .4); compiles to foo: rgba(1, 2, 3, .4); so I'm not quite sure where you got this idea of these functions being a polyfills at all.

In a long run I guess we could consider to return to a generic idea (mentioned many times here and there in various issues) of "not evaluating things until they are actually used" but it's something more complex than just "removing" rgba et al functions.

[matthew-dean]

It depends on what you mean with "polyfilled". Note for example the built-in rgba is not really a polyfill simply because of something like darken(rgba(1, 2, 3, .4), 5%) <- here it must be evaluated as a Less function that accepts some args (numbers in a simple case) and returns a built-in color object for a further manipulation.

That's a good point. So if we need to evaluate it sometimes, we can't really remove the function. 🤔

In a long run I guess we could consider to return to a generic idea (mentioned many times here and there in various issues) of "not evaluating things until they are actually used" but it's something more complex than just "removing" rgba et al functions.

Yeah maybe that's the better approach.

[matthew-dean]

I renamed this but I think I'll close this in favor of discussion at #2986.

[shrpne]

@matthew-dean @seven-phases-max
How about renaming Less color functions to something with a prefix?
For example: toRgba, makeRgba, colorRgba etc.
So they will not conflict with CSS functions.

[seven-phases-max]

@shrpne I think that will very spoil the very purpose of the whole thing. It's not just about "some Less functions" - it's about The Colors (as universal thing) in Less. It's not some rgba or so, it's also the same thing with any other color representations like #123, red and so on (will you also purpose some less-hex-color(123), less-red and etc?). There's no point in having things like:

@some-color: *any ordinal value here*; // please don't force me to use some freaking crypted garbage here, it's not what I installed Less for and bother with it at all 
/*

































*/
foo {
   bar: darken(@some-color, 5%);
}

Yes, it may be conflicting with some newest CSS stuff but that's what things like #2986 are for.

For the rest honestly I don't see the point in using Less then at all. For 100% CSS-compatibility one just uses CSS. If we are for some superset language we automatically agree it may be incompatible (hopefully temporary) at some point.