ColorPicker's colorspace not respected for output

[timelsass]

Describe the bug
When selecting a colorspace in a ColorPicker component, I would expect that the colorspace is respected for output. It appears things are ran through tinycolor and just out put as RGB for custom colors inline.

To Reproduce
Steps to reproduce the behavior:

1. Add a paragraph block.
2. Open the ColorPicker from the ColorPalette.
3. Change the colorspace to HSL.
4. Change the background color to some custom color using the control.
5. Inspect the editor where the background color was changed. Take not that the color was applied in the editor as RGB (despite having selected HSL).
6. Save and publish the post.

The result is that the background color has now been set to a HEX value on the frontend.

Expected behavior

I expected to see the chosen colorspace respected for frontend (and in-editor) output. In the editor it appears that the colors are all applied as RGB, and the frontend are all applied in HEX.

Desktop (please complete the following information):

• OS: Ubuntu 18.04.1 LTS
• chrome
• Version 69.0.3497.92 (Official Build) (64-bit)

Additional context

• Gutenberg 4.3.0

[RobStino]

Noticed this as well.
Additionally, the current user experience of inputting in the editor with one type of color value (e.g. HSL) and then having it switched to RGB next time the block is opened again doesn't feel right. It would be expected that the type used for input should persist in the editing experience as well as what is described above in actual output.

[skorasaurus]

Confirmed this behavior - Despite selecting HSL in the colorpicker; In the editor it appears that the colors are all applied as RGB, and the frontend are all applied in HEX. - is reproducible in Gutenberg 11.7.0.

should be tracked in #34284

[skorasaurus]

Still an issue in Gutenberg 14.6; in addition, colors edited in HSL; when exported by the theme (in global styles) are saved as HEX values. :(

We would like to represent our colors in HSL but this makes it impossible.