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
While this might be fixed by transitioning to use of a common / universal color definition for internal storage (i.e. all colours are instances of a generalised colour definition, converted on demand to whatever format is requested), until then I think there is a case for defining an additional property for colour classes which evaluates to 0->1 opacity.
Consider this example - imagine you do the following:
If you then want to convert this to RGBA you might do
echo $the_colour->rbga($the_color->alpha()); // error - due to alpha (55) value being out of required range (0->1)
So to make this conversion the developer using library needs to first check what format the colour being converted is and adjust the alpha value to one that will be accepted by the RGBA method. This is unnecessary, and by making it happen outside of the library increases liklihood of errors being introduced.
A better solution might be to calculate an "opacity" value for each colour definition - translating whatever opacity format information is held in the colour format into a value in range 0->1 - so in this case the hex 55 value would translate into 0.33 opacity value.
Then developers could use the following form without worry:
because this issue seems to be inactive for quite some time now, I've automatically closed it. If you feel this issue deserves some attention from my human colleagues feel free to reopen it.
While this might be fixed by transitioning to use of a common / universal color definition for internal storage (i.e. all colours are instances of a generalised colour definition, converted on demand to whatever format is requested), until then I think there is a case for defining an additional property for colour classes which evaluates to 0->1 opacity.
Consider this example - imagine you do the following:
If you then want to convert this to RGBA you might do
So to make this conversion the developer using library needs to first check what format the colour being converted is and adjust the alpha value to one that will be accepted by the RGBA method. This is unnecessary, and by making it happen outside of the library increases liklihood of errors being introduced.
A better solution might be to calculate an "opacity" value for each colour definition - translating whatever opacity format information is held in the colour format into a value in range 0->1 - so in this case the hex 55 value would translate into 0.33 opacity value.
Then developers could use the following form without worry:
Does this sound like it is worth doing? Or is work on a unified colour model a better thing to spend time on?
The text was updated successfully, but these errors were encountered: