Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add input validation #30

Open
denmch opened this issue Mar 18, 2019 · 3 comments
Open

Add input validation #30

denmch opened this issue Mar 18, 2019 · 3 comments

Comments

@denmch
Copy link

denmch commented Mar 18, 2019

I love this site, both because it's so attractive and easy to use, and because it allows me to test colors with alpha values. Thank you!

One thing I noticed while playing around with it, though, was that there's no indicator when a user enters an invalid color code. If the input is invalid, the last valid entry silently remains. If a user enters an invalid color, the new pairs seems to be just as the last valid pair.

For example, the page begins with:

white / hsla(200,0%,0%,.7)

If a user modifies the foreground number and misses a percent sign or pastes a malformed color code, output and #results remain unchanged, and the user may believe that their malformed color code is both valid and accessible, based on the unchanged success message.

For example, each of the following invalid foreground colors will appear to be successful:

white / hsla(200,0,0%,.7) (missing percent sign on saturation)
white / hsla(0%,0%,100%,0) (erroneous percent sign on hue)
white / bloop! (invalid color name)

Swapping the colors then fails because the invalid color code can't update the background color, so that both colors are now identical, i.e., reversing "white / bloop!" says "bloop! / white" but the actual colors being compared are "white / white."

I wasn't quite able to see how colors were being parsed, but it'd be great to work out validation for color codes so that users, especially those less familiar with how the different types are formed, can see where they've made mistakes in using the tool (e.g., it's easy for beginners to a percent sign, or confuse RGB and HSL).

Thanks.

(P.S.: I'd like to help out if I can, but I'm feeling a bit dense in trying to see how the inputs are parsed.)

ukanuk added a commit to ukanuk/contrast-ratio that referenced this issue May 6, 2020
@ukanuk
Copy link
Contributor

ukanuk commented May 6, 2020

Do you think something like this would be helpful, where I've added "Current Color" as in the screenshot below? This only changes when the background color actually updates. I've done this on the show-evaluated-color branch of my fork (I will submit a PR to merge changes if they're actually helpful).

It could be improved by showing both RGB, HSL, hex codes, and named colors (e.g. red), to make the colors easier to recognize.

image

@LeaVerou
Copy link
Collaborator

LeaVerou commented May 6, 2020

Hey @ukanuk, thank you for working on this, I appreciate it!

However, I would prefer some sort of indication that the color is unsupported instead (e.g. a red border, possibly a ⚠️ and/or the text "unsupported color"). I see a bunch of problems with the current color approach:

  • As a user, I have no idea what this means
  • It does not communicate that my input is incorrect
  • I may have entered a perfectly valid color, that is just not supported by the browser (e.g. lch(50% 10 300).

@ukanuk
Copy link
Contributor

ukanuk commented May 7, 2020

How about this? The box shadow is replaced by a red glow with invalid input.

image

ukanuk added a commit to ukanuk/contrast-ratio that referenced this issue May 7, 2020
This reverts commit dfc5585.
ukanuk added a commit to ukanuk/contrast-ratio that referenced this issue May 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants