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

Update button and link colors for themes #2026

Open
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

hichemfantar
Copy link
Contributor

@hichemfantar hichemfantar commented Jan 17, 2025

Adjust button title color and link colors to improve visibility in both dark and light themes.

image

@hichemfantar hichemfantar marked this pull request as ready for review January 17, 2025 17:56
Copy link

github-actions bot commented Jan 17, 2025

@josevalim
Copy link
Member

Thank you @hichemfantar. One issue with this change is that we also use ExDoc to generate docs for Erlang, and now links in Erlang and Elixir would look different. Plus links in Erlang would look in red, which was too distracting. I am afraid we may not go ahead with this one. :(

@hichemfantar
Copy link
Contributor Author

Let me see what it looks like in erlang and I’ll get back to you

@josevalim
Copy link
Member

I believe you can do mix build --proglang erlang or mix docs --proglang elixir. But generally we would want to keep the content between the two consistent.

@hichemfantar
Copy link
Contributor Author

hichemfantar commented Jan 17, 2025

light mode already looks good but i changed to a lighter shade in dark mode and it looks good

current
image

after
image

passes wcag
image

light
image

elixir
image

@josevalim
Copy link
Member

Yes, I think the red links are too jarring, sorry. :( If the current ones do not offer enough contrast, then we can address that, but it would be best if the link colors are not theme dependent. Thanks!

@hichemfantar
Copy link
Contributor Author

here's another sample zoomed out, you can see it's hard to distinguish links from regular text (the red is also easier on the eyes because it feels the bold white text is too bright)

image

image

@hichemfantar
Copy link
Contributor Author

hichemfantar commented Jan 17, 2025

also there needs to sufficient contrast between link text colors and non link text colors. it's why browsers by default use blue for links

image

@josevalim
Copy link
Member

I actually think using blue, the browser default, would be a great idea. It is not theme specific and addresses all issues. WDYT?

@hichemfantar
Copy link
Contributor Author

sounds good, i'll give it a shot

@hichemfantar
Copy link
Contributor Author

hichemfantar commented Jan 17, 2025

should be good now, using the default chrome link colors

@josevalim
Copy link
Member

Thanks. I think there are some regressions:

Screenshot 2025-01-17 at 21 49 05

I believe the Callbacks, Functions, etc should not use the browser style. I'd also change the underline below links to follow browser style as well. Have them in black feel a bit weird, wdyt?

@josevalim
Copy link
Member

The plot thickens. It seems we already have a blue color for links, which is what we use for "code links" in Erlang:

Screenshot 2025-01-17 at 21 52 14

We should probably make it so that both links and code links follow the same style and same color in both Erlang/Elixir. I think this PR still keeps Elixir code links in a purpleish color.

@hichemfantar
Copy link
Contributor Author

hichemfantar commented Jan 17, 2025

i believe we have reached the ending of this story.
everything now should work as expected and underline uses the same color as the link.

@hichemfantar
Copy link
Contributor Author

perhaps get rid the of the noUnderline variables and just name them links?
linksNoUnderline -> links
linksNoUnderlineVisited -> linksVisited

@hichemfantar
Copy link
Contributor Author

renamed the variables to be clearer and got rid of duplicates

@hichemfantar
Copy link
Contributor Author

please tell me everything looks good on your end so we could put this saga to an end

@hichemfantar
Copy link
Contributor Author

Web Content Accessibility criteria here we come

--linksNoUnderline: var(--mainLightest);
--linksNoUnderlineVisited: var(--mainLight);
--link-color: var(--mainLightest);
--link-visited-color: var(--mainLight);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, to be clear, I was thinking we should move these out of the language custom props and use the same for both languages (so they would go to the general prop definitions). I think having both languages use the same colors for links would be a huge plus for overall ecosystem consistency. Thoughts?

@josevalim
Copy link
Member

I took a look at main and it looks really clean, except the Summary headers and the API reference pages are still being shown as links, as they should have their previous styling (we consider them to be headers):

Screenshot 2025-01-18 at 09 23 31

They already have .summary and .summary-signature headers, so it should be easy to address. Thoughts?

@hichemfantar
Copy link
Contributor Author

I think they should remain clear as links, i actually didn't even know they were clickable until i enabled link coloring.
goes to show you the importance of accessibility guidelines adherence and the ability to be able to differentiate between regular text and clickable links.
I also had an annoying thing happen where i tried to copy the header text and since it wasn't clear that it was a link, i ended accidentally navigating to a different section.

@hichemfantar
Copy link
Contributor Author

btw perhaps get rid of italic because i believe it lowers readability without offering anything?

before
image

after
image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants