Support for CSS Color 4 syntax

[kajkal]

MapLibre GL supports only color values (rgb/hsl etc) defined with commas, newer syntax, CSS Color 4 ready, without commas is not supported.

Paint style: "fill-color": "hsl(0 0% 83%)" in layers currently results in an error: layers[0].paint.fill-color: color expected, "hsl(0 0% 83%)" found.

Would it be possible to migrate from csscolorparser to more modern css-color parsing library, for example colorjs.io?

As a bonus, the color interpolation logic from the src/util/color_spaces.ts could be delegated to the said library.

[HarelM]

This sounds very interesting!
Is there an equivalent for this in the native world?

[kajkal]

Oh, I was not even aware that such an equivalent is required. I thought that this library was solely responsible for style (color) related stuff but now I see that MapLibre GL Native uses c++ port of the mentioned csscolorparser js library.

I found one promising library - csscolorparser-rs but it is written in rust, so I’m not sure if it would be feasible/easy to integrate it with the MapLibre GL Native c++ codebase. There is also css-color-cpp, but it is unproven and without tests.
Someone from the native world would have to look at it.

[HarelM]

This repo is for the spec, which serves both the web and native libraries, thus the ask.
Cc: @ovivoda @louwers

[louwers]

@kajkal I think it should be possible for the spec to evolve independently of the implementations. If this gets added to the spec we should probably track which of web or native has support for it. We would create an issue for both in the respective repos, and maybe link to those issues from here. Sounds very doable but as maintainers we are not reponsibile for development.

[HarelM]

@louwers I think the main question here is if this sounds possible to support this request in native? If possible, I would like to avoid accepting to change the spec without making sure we can, eventually, support it in both platforms.
From web point of view, this doesn't sound complicated.

[louwers]

If possible, I would like to avoid accepting to change the spec without making sure we can, eventually, support it in both platforms.

Good point. Definitely sounds possible!

[HarelM]

Since we support css syntax for colors I think we should extend it to support css color 4.
If you decide to open a PR to replace csscolorparser, please make sure to also open a PR for the core repo to remove this now unused dependency.

[kajkal]

I created PR #79. But there were some problems. colorjs.io procedural api, which I decided to use, is defined solely as an ESM module so I needed to change tests configuration based on the official experimental jest documentation. In addition, the generated .cjs modules are not able to import code from the external ESM library and do not work, the failing test is related to that. Are these .cjs still even necessary? 😅 Generated scripts with the .mjs extension fortunately work. Build configuration stuff is definitely not my strength. If this PR was to be accepted it would be great if some build configuration wizard would look at it.

The final size of the maplibre-gl-js library bundle increased from 740kB to 755kB (194kB => 200kB gzip).

On the bright side, CSS color 4 is supported and color interpolation now works somewhat more predictably, see below. And I addressed some edge cases such as interpolation from rgba(255, 0, 0, 0) to rgba(0, 255, 0, 1) which is, in current version, interpreted as rgba(0, 0, 0, 0) to rgba(0, 255, 0, 1), all that initial redness is ignored! This is of course not limited to red only, any color that has zero alpha is ignored in the current version. Below is a visual presentation, last example:

^Image shows 3 interpolation ranges each in 3 different color spaces, side-by-side comparison of the current version 3.0.0-pre.4 with the changes proposed in this RP. Live demo here.

In addition, there should be some performance improvement when interpolating colors in a space other than sRGB. When calculating each interpolation point, the cached color conversion result from sRGB to the target space is used - with the current version of maplibre-gl-js, these calculations are repeated for each of the mentioned points, which between the 2 colors can be counted in hundreds, and in addition, each change of zoom results in their next re-recalculation.

[kajkal]

I closed PR #79 but I opened PR #94 where the size of the bundle increased from 740kB to 744kB (194kB => 196kB gzip). In it, I used the smallest reliable color parsing library I could find. There are some things in it that are not used in parsing (like serialization), but it seems to me that further reduction could only be achieved by writing your own custom colors library. If in the future someone finds a better parsing library option, changing it should not be complicated.

I have attempted to resuscitate the color interpolation code, and the results can be viewed on the updated demo in which you can quickly change the color ranges and see how interpolation work on different versions.