argyleink
commented
3 years ago Hi @hmnd!
I think in a best case scenario, both would be present! Folks on Safari or Chrome may already be accustomed to the color picker, as it's found in many other places in their operating system or workflow, meanwhile, VisBug could have a setting that says "use built in color picker or visbug provided picker". You're right, some folks want a normalized picker and it'd be nice to offer one.
Then there's the output and input, like color in and out, as opposed to the user side of things. The built in color pickers are primitive and visbug works with it right now since it's HTML standard. Visbug would need taught to work with a new color picker, which isnt too much work, but has some tradeoffs. Standards APIs vs Plugin APIs.
Also, there's display-p3 and LAB coming soon, and theoretically the built in color pickers will have this new feature, to pick colors in these new gamuts. (Safari has one in their devtools). By sticking with the standard, those are available as soon as the browser updates, as opposed to when a plugin updates.
I've also looked at tons of color pickers lol. I'd love to use one that was perceptual color based, like HSLUV's, but felt like that was too opinionated hehe.
There's so much to think about! I've shared a few thoughts and don't want to go too long. What do you think of some of these?
Jumping off of #424, the color picker in Firefox on Windows is rather inferior to the one available in current versions of Chromium-based browsers. Since VisBug uses the browser's native color picker, that's understandable. However, it would be great if VisBug included its own color picker implementation so the experience could be more consistent. I think something similar to pickr would be nice—not too dissimilar from Chromium's picker either.