Open kuon opened 5 years ago
I would definitely use this in my project. I think css colors are a de-facto interchange format for colors on the web, so if you need interop with a system you don't control, CSS colors are going to come into play.
Whether it should be in the core package is another question. Personally I'm a fan of a batteries included approach, so would support that.
@kuon you mentioned you possibly had some existing code for this? Can you list the formats that it's able to parse?
rgb() rgba() hsl() hsla() and hex
(both percentage and 0-255 ranges) it was written for 0.18
https://gist.github.com/kuon/19b14cd5f913c8b60c08dbbdb0156514
Consider it BSD3 licensed.
I read your hex parser and I think yours is better as it uses pattern matching instead of regex.
You should probably also include keyword colors in the parser:
Well wouldn't using a dict be faster for color names? I also think it should be case insensitive.
I used regex for my parser, but with elm/parser now available maybe it would be better to use it for the CSS formats.
My use case is interfacing with an existing system that uses css colors. I don't control that system so can't change it to a different format (nor would I want to, it's a totally reasonable choice in context.)
In my case, that information is coming in json, so my ideal situation would be to have a Decoder Color
, but I'd be fine with any String -> Maybe Color
or String -> Result Color
. (I'd like to detect errors and fail the decoding rather than choose a default.)
Since this functionality is not exposed, I'm planning on reimplementing or copying an existing parser, which is not ideal.
My use case for CSS color parser is a WYSIWYG editor that produces CSS colors, the rendering is done in elm, I adjust some of the colors before rendering (like ensuring contrast...), that's where I need a CSS color parser.
Follow up of: https://github.com/avh4/elm-color/issues/4#issuecomment-419789478