You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, Color.js supports parsing and serializing into a variety of formats, but it's exceedingly difficult to roundtrip in a way that doesn't switch to a different format.
This results in subpar user experiences where e.g. the user will input "oklch(0.6 20% 180deg)" and the UI will change their input to oklch(60% 0.08 180). For a demonstration, try editing the swatch in this <color-picker> component I’m working on.
However, parse() actually does keep track of metadata like what format was used and what was the coordinate type for each coordinate, it's just that serialize() doesn't really have a way to take advantage of it. It does not even expose a way to customize the output type of a specific component without having to completely redefine the format, a common user pain point.
I propose:
serialize() should accept an array or object for coordinate types (e.g. ["<percentage>", "<number>", "<angle>"] or {l: "<number>", c: "<percentage>"}). Perhaps coordTypes?
In the OOP API, Color objects that have been created by parsing strings, should keep track of the parsing metadata (e.g. in a symbol field). Folks using the procedural API can manage it on their own.
color.toString() should take advantage of any parsing metadata stored in color and serialize to the same format
Currently, Color.js supports parsing and serializing into a variety of formats, but it's exceedingly difficult to roundtrip in a way that doesn't switch to a different format.
This results in subpar user experiences where e.g. the user will input "oklch(0.6 20% 180deg)" and the UI will change their input to
oklch(60% 0.08 180)
. For a demonstration, try editing the swatch in this<color-picker>
component I’m working on.However,
parse()
actually does keep track of metadata like what format was used and what was the coordinate type for each coordinate, it's just thatserialize()
doesn't really have a way to take advantage of it. It does not even expose a way to customize the output type of a specific component without having to completely redefine the format, a common user pain point.I propose:
serialize()
should accept an array or object for coordinate types (e.g.["<percentage>", "<number>", "<angle>"]
or{l: "<number>", c: "<percentage>"}
). PerhapscoordTypes
?Color
objects that have been created by parsing strings, should keep track of the parsing metadata (e.g. in a symbol field). Folks using the procedural API can manage it on their own.color.toString()
should take advantage of any parsing metadata stored incolor
and serialize to the same formatThoughts?
serialize()
output types without having to specify a whole format #525Color
instances #535The text was updated successfully, but these errors were encountered: