WIP: feat(color): Rewrite color in terms of css-color-4
(I intend to fully explain this at a later point, but I'm filing this now to facilitate parallel development and the feedback loop. It's still a work in progress.)
@emilio @tiaanl
Also, I believe Tiaan was planning on changing the color representation to be a bit more unified, something like:
TLDR: I think the calculation optimized representation ((color_space, f32, f32, f32, f32))should stay in gecko and we just convert to that from whatever the parser gives us.
Right now I take in whatever the parser gives me and transform it into the ~(color_space, f32, f32, f32, f32). The plan was to move that into the parser once i implement the color() function. I'm not 100% sure if we should do that though. Not doing so will give us more flexibility to change things for better calculations inside Gecko without changing how things are parsed. Downside is there are some computation and memory overhead for converting. Not huge structures, so should be OK, but a benchmark should be done. As a consumer of this library I would rather get as much detail from the parsed values as some flat optimized representation.
Bah, tests for #312 rely on color parsing.
:umbrella: The latest upstream changes (presumably #313) made this pull request unmergeable. Please resolve the merge conflicts.
A number of spec changes have been made as a result of this work, but it does likely mean portions of the code will need to be changed (hopefully to simplify them).
I still have to go through and evaluate them.
:umbrella: The latest upstream changes (presumably 7c580083e60771f12a4d4886010126c14432a53d) made this pull request unmergeable. Please resolve the merge conflicts.