search

less / less.js

Less. The dynamic stylesheet language.
http://lesscss.org
Apache License 2.0
17.02k stars 3.41k forks source link

feature request: Space-separated functional color notations support #3547

Closed troy351 closed 3 years ago

troy351 commented 4 years ago

Since Chrome DevTool's color picker already using the modern CSS color syntax, less should support it too. e.g. rgb(255 0 0 / 50%), hsl(0deg 100% 50% / 50%) https://bugs.chromium.org/p/chromium/issues/detail?id=1072952

Also, one can be achieved by using ~"/" instead of /, but a little verbose

matthew-dean commented 4 years ago

TL;DR - This color proposal is still in working draft, so nothing will be done immediately about it, but as a parser that allows JS functions, we need to start thinking about it.

I knew this was coming down the pipe, so this is something to acknowledge as an issue sooner rather than later. Not in the least, having comma-less arguments is sort of fine for CSS (although why W3C thinks this is necessary, I have no idea).

But this really muddies the waters for functions defined in JS, because of the ambiguity (unless JS functions only allow comma [and, in Less, semi-colon] syntax). CSS values are terribly grammatically ambiguous. A single CSS value can be a single unit, or a space-separated value, or a comma-separated value, so what a CSS accepts as an argument is defined specifically by that function's specification.

So I'm just wondering how to approach this from a parsing / feature perspective:

  1. White-list specific functions with this syntax? (May be less maintainable)
  2. Move argument parsing to functions? (Not ideal)
  3. Let JS functions define the "style" of arguments they can receive (e.g. single values, a list of space-separated values... etc)
troy351 commented 4 years ago

Thanks for your reply. Although the new spec is still in draft, latest stable version of Chrome (i.e. Chrome 84) already used it. I think many developers would copy the color value from DevTools back to their less code during development as I did. And now this becomes a bit annoying.

Also, I’m aware of SCSS did it well since brackets was needed for divide operation. But it would be a breaking change if brings this feature to less

matthew-dean commented 4 years ago

@troy351

Also, I’m aware of SCSS did it well since brackets was needed for divide operation. But it would be a breaking change if brings this feature to less

Less has that option too parens-division, and it is the intended default for Less 4.0.

troy351 commented 4 years ago

OMG! I didn't know that. So I just need to replace all / by ./ and problem solved!

BTW, when will 4.0 be ready?

matthew-dean commented 4 years ago

OMG! I didn't know that. So I just need to replace all / by ./ and problem solved!

The better way might be to set the math setting in Less options: http://lesscss.org/usage/#less-options-math

BTW, when will 4.0 be ready?

There's no current timeline for this. It's ready when it's ready. 😉

troy351 commented 4 years ago

OMG! I didn't know that. So I just need to replace all / by ./ and problem solved!

Yeah, what I mean is to make the old code work under new options.

Should I close this issue since I have already fixed my problem? But the problem title says still remains

matthew-dean commented 4 years ago

Should I close this issue since I have already fixed my problem? But the problem title says still remains

There's a workaround but I think it's an important feature request to implement. It's not just allowing the function to parse, Less also needs to understand that syntax as a color so you can pass it into Less color functions.

troy351 commented 4 years ago

Makes sense, I'll leave this issue open

matthew-dean commented 3 years ago

Released in 4.0