-
Notifications
You must be signed in to change notification settings - Fork 86
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
Material background on KTextbox #139
Material background on KTextbox #139
Conversation
I don't recall why this is a draft "Until we get KSelect" in. I actually am okay now with merging it. The fact that KSelect will still be without the background (like in the image below) isn't super offensive compared to the images included at the top. @indirectlylit @jtamiace do you agree? |
I'm interpreting that the main benefit of waiting would be to have complete consistency once this background color change is merged in? I guess my question is how prevalent KSelect is. If like half of them would end up with different backgrounds, may be worth waiting. If there are only a few KSelects, probably ok? |
@jtamiace I don't think it's very prevalent. The only places I can think of are in table filters and a couple of device and/or facility settings. |
Cool. It's a 👍 for me then! |
same here |
@radinamatic can you give us the darkest compliant grey value for the label case? The error text looks much lighter than our token which should be red 700 ( |
With the red 700 ( Our main purple was already on the edge, so the only compliant background color would be (Crazy idea) |
@radinamatic for the context of this change see #167 |
We could also choose a darker purple from our palette that's compliant with |
b0040f9
to
8bab49e
Compare
@radinamatic @jtamiace @indirectlylit I've updated to use more accessible colors - but I did not change the background to a lighter grey for reasons to be mentioned below:
So - I darkened the purple to An alternative thought is that we could change the themeTokens.error to use the slightly darker red that themeTokens.incorrect uses, which passes the WebAIM AA test (but not the AAA): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for doing this exploration @nucleogenesis!
I chose these tokens somewhat arbitrarily – there was not an intentional design decision to use different red shades for the two meanings. |
where `primary` was used also changes `themeTokens.error` to use the `red.v_800` that `themeTokens.incorrect` does to improve a11y and because it wasn't chosen with any particular purpose learningequality#139 (comment)
Thanks @indirectlylit - I've changed the theme to use the darker red now - will await an approval from @radinamatic and if she's good with this then will merge |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
primaryDark
is looking much better!!! 💯
Thank you, Jacob! 👍🏽
This is a draft for now - this should not be merged until KSelect is also available in KDS and has the same or similar styles applied.
Fixes #124
Fixes #167
translate()
CSS function to ensure the label is centered (original value pushed the label to the baseline)
empty div fallback for the part of the DOM flow where the error/help message would show. A counter shows on the same horizontal line but isposition: absolute;
so when there is no help/error text, subsequent elements are closer to the previous one than they ought to be and they look squished.I took this first screenshot w/ a delay feature on my screenshot extension so I could properly focus the field to show that the theme colors work still.
These are just a few more examples with error messages, text, no text.+