Model named colors as `Color` instances instead of strings
oliverklee opened this issue · comments
Looking at the class hierarchy, Color extends CSSFunction extends ValueList extends Value. But a named colour would be neither a CSSFunction nor a ValueList - though would be a Color. Not sure how best to reconcile this. In #353 I suggested the possibility of a Keyword/Identifier type that could represent a any sort of named value, including a named color and a border-style, with the non-specific type simply wrapping a string (of unknown meaning). Something to think about...
Not sure how best to reconcile this.
Maybe the named colour class type would need to be quite separate in the class inheritance hierarchy, focusing more on how it is parsed than what it actually represents. If there's a need to provide common functionality between named colours and RGB colours, an interface could be provided, which both implement. That interface might be Color, with the existing Color being renamed to RgbColor.
These are just thoughts that might help with the design for this change.
IMHO named colors should be parsed into rgb colors with an additional flag. On output, these could be rendered to names again using a reverse-lookup table.
Also, we should add format options on whether to prefer outputting colors the way they were input, or as hex, as function, or as named (if possible).