feat: add color pickers #50
Conversation
Signed-off-by: Seth Falco <seth@falco.fun>
|
Hey, thanks for working on this! My understanding of how people use this site is that they already have a color pair to compute, so they are pasting it in, and often adjusting it to pass (hence the Incrementable). Have you come across use cases where people actually pick the colors in the contrast checker? Have you needed it? (I'm not opposed to it, but a sanity check is always useful, so that we don't add features just for completeness) |
|
Yeah, I actually wanted to PR this for a while for my own usage! I don't use the native increment feature/library myself since I mostly play with hex, but I do manually adjust the hex values in increments when under the same use-case you covered. (i.e. I know the 2 colors I want like with links, but just need to get the readability.) However, I do find myself favoring the color picker in some cases, these are listed in order of occurrence:
To cover 1, I've worked around it by taking a screenshot, pasting it in GIMP, then using the eyedrop tool and pasting the values over to the site which is a bit cumbersome. ^-^' That's also why I highlighted something I think is great is being able to use the eyedrop tool from the native color picker that pops up, since then, I can just open whatever I'm reviewing and use the eyedropper to select the colors out of it. It's worth noting I don't only rely on this tool for web development, but within things like graphics design as well. For me, it's less about background color + text, and more about background color + subject. If anything, maybe the example text should even feature some SVG icons and such! |
| * Make each element with an ID a global variable. | ||
| * Many browsers do this anyway (it’s in the HTML5 spec), so it ensures consistency. | ||
| * | ||
| * https://html.spec.whatwg.org/multipage/window-object.html#named-access-on-the-window-object |
There was a problem hiding this comment.
This reminds me, at this point is there any current browser that doesn't do this? If not, we could just remove this code.
There was a problem hiding this comment.
This comment actually taught me that this was a thing at all. I had no idea this was standard behavior. When I looked into it, I mostly found comments to avoid depending on that part of the spec, though. (i.e. if in future there is a global called background, then it'll break the site) ^-^'
I can only confirm that Chromium and Firefox Nightly have this behavior by default, though. Not sure what I'd search on Can I Use to check for this. 🤔
There was a problem hiding this comment.
Yeah, we should probably keep the loop but assign them to some custom object (e.g. dom).
|
Thank you for the extensive feedback on how you use contrast-ratio! I'm fine to merge this, can't hurt and I don't see any issues with it. We'll ditch the
This is why adjusting in RGB (including hex) is a generally a poor idea for adjusting lightness or luminance. HSL works much better for that, and soon LCh/Oklch will work even better. |
Not sure about the UI/UX for this, but I've added color pickers now without removing anything that already existed. We should probably have an icon or something to indicate it's for picking color, but I need to give this more thought or ask a designer or something. 🤔
I use the native
colorinput type of the device, for the most part this should offer the most comfortable experience for the user. This also offers a very practical feature as users can use the eyedropper tool to select a color from somewhere else on the screen, including outside of the browserIt works with 1 caveat!
It seems
input[type=color]only supports#RRGGBBwithout alpha. So if a color is typed in manually which featured the alpha component, the color picker will show the color without alpha applied.This is visible at the start of the GIF attached which shows the color
hsla(200%, 0%, 0%, .7), with the alpha channel stripped off, this is ultimately black so the color picker displays the color black.Relates to