Add color change on hover for all anchors
Resources
FE @alfredo1
Final design
All anchors will change their color to #005299 on hover and focus. That includes anchors that were originally blue (#3777b0) and those that were a shade of gray.
New direction
All anchors should change their color on hover. We have many links in GitLab that don't change their color on hover/focus/active, so in this issue we will propose colors for those secondary states.
Original description
There are some anchors that suffer a color change on hover and focus in addition to being underlined.
I've found two examples where this isn't necessary as the underlining is enough and the alternate color is less pleasing.
Related Merge Request on Issue page
Default state
Hover
Lists under profile settings. For example, under the Notifications tab.
Default state
Hover
The color change should be removed for both hover and focus states. If anyone finds more examples of this, please add them to this issue.
Activity
Mentioned in issue #24062 (moved)
Hm the darker color change is actually the correct (original) hover state. The instances where it does not change color is happening from an override. I personally don't mind the color change but I agree it should be consistent. @awhildy any thoughts on which way this should go?
The downside of darkening the link on hover is it actually makes it stand out less if it is in a paragraph of text. While this doesn't matter too much for hover (as hopefully you are already looking at the link), it may make keyboard focus state less obvious. Definitely agree that it should be consistent, I could see the argument either way, but I do lean slightly towards removing the color change.
We should be consistent with this. @awhildy for focus state the links would probably have a blue glow, so I think that is visually apparent.
-
Yeah, agree with @pedroms here regarding the focus state. There should be a more obvious visual indication on focus than the text-decoration or color. Pedro what are your thoughts on removing the color change on hover? I could see the argument for the color looking more like paragraph text on hover but it also provides another visual cue.
@tauriedavis @pedroms @awhildy All text links have the Bootstrap glow on focus, so I don't think there'd be a problem with people missing the link in that state.
On the topic of consistency, I think most of our blue links don't change color on hover (for example when you mention a user or issue in a comment), but the grey ones do by becoming a darker shade of grey or blue. In that sense, we could have a separation of blue links vs. grey links and change the color for one of them an not the other, or we could apply the same rules to all links and always change the color.
I don't like the darker blue color that inspired this issue, but the more I think about it, the more it makes sense to treat all links equally. A good solution could be to give all links a color change, but choose those colors carefully so they look better than what we have now.
Mentioned in issue #24149 (closed)
For the best accessibility, I think every action that is not a button should have some additional element on hover (a border, underline, dot, whatever). We should not rely only on color change. For example, look at @cperessini's comment above and try hovering the mentions, his name and the “commented…” time stamp. It doesn't make sense for those links in the comment header to not have an underline.
I agree that it's better to have color change. But, as @cperessini pointed out, the current hover color can be too dark and blend with the surrounding dark gray/black text. One way to solve this may be to darken the blue a bit, but also increase its saturation. Take a look at this quick example:
First link is normal, unchanged. Second link with 100% saturation and 30% lightness (#005299). Third link has current :hover color (#255076).
-
@pedroms Agreed, all anchors should have an underline on hover. We should start an MR for #24129 (moved) so we can get it done.
Since we agreed we should have a color change for all links, I've compiled a list of all the changes I think we need to make.
@pedroms The color you chose for anchors is good, but I had already made all the gifs using another color (
#2e699c). We can use either, though.Navigation, group and project name
Current
#5c5c5c
Proposal
#333333
Issue/Merge Request, author
Current
#5c5c5c
Proposal
#333333
Issue/Merge Request, anchors
Current
#3777b0
Proposal
#2e699c
Issue, related MRs
Current
#255076
Proposal
#2e699c
List item, title
Current
#333333
Proposal
#000000
List item, anchors
Current
#333333
Proposal 1
#3777b0
Proposal 2
#000000
List in profile settings, anchors
Current
#255076
Proposal
#2e699c
Project page, quick links
Current
#686868
Proposal
#3777b0
Repository, file name
Current
#333333
Proposal
#000000
Todos, project name
Current
#777777
Proposal 2
#3777b0
Proposal 2
#5c5c5c
Edited by Chris Peressini @cperessini Oh, thanks for noting that you already had a custom hover color. I prefer it darker and saturated. I've placed mine (
#005299) and yours (#2e699c) side-by-side, see which one you prefer:
After looking through your proposals (thanks by the way), I couldn't help but think: how would we decide in future situations what hover colors should be used? Which lead me to: why don't we simply use the same blue hover color for every link? Is there any negative aspect to it?
-
@pedroms Yours is definitely more noticeable. I'll play around with them and see how they look in different environments.
I thought about doing that, and you can test it by adding a rule to
a:hoverin the web inspector, but after seeing it live I thought it looked to heavy. It's good to have a more understated style for certain links. In my previous comments I used a shade of gray for the anchors where I thought that was the case, but feel free to propose any changes if you think differently. @cperessini I understand, thank you for explaining. Our UX guidelines for anchor links state:
An underline should always be added on hover. A gray link becomes blue on hover.
Of course, this can and should evolve if necessary. My question is to know what the rule is so that we can apply it consistently. I think that gray/dark gray/black links are already understated on their own, so I don't see why they can't turn blue on hover since you are focusing your attention on them.
Milestone changed to %8.15
-
We are now turning the black nav and sub nav links blue on hover (I think the color in my MR will need to be updated to what we decide here). I think this is another reason we should just make everything consistent and turn black links blue on hover as well. We already do this for some black links, like the ones on the sidebar.
Awesome work on all those gifs @cperessini !
-
Do you have an MR started for this issue @cperessini ?
-
I've been playing around with making all anchors turn dark blue and I think it can work okay. I think the problem I was seeing before was the change from a dark color like
#333to our light anchor color, which looked a little jarring.I made some screen recordings to show the difference between the color Pedro proposed (
#005299) and the one I had used previously (2e699c). The more saturated color (#005299) looks a little intense to me, maybe because it reminds me more of the classic0000ffthat everyone used to use for anchors, but I'd love to get your opinions because it's not just me who will be looking at these links all day.File tree in repository
#2e699c#005299Issue
#2e699c#005299Projects list
#2e699c#005299@tauriedavis I tried to implement these changes, but it got a little complicated, so I never created an MR.
Mentioned in merge request !7639 (merged)
-
@cperessini: I think I have a very slight preference for #2e699c. Thanks!
@cperessini Thanks for making those clips, it really helps
#005299). Mostly because of the difference when you hover a normal blue link. I think the less saturated one (#2e699c) is too subtle when hovering normal blue links. If you still think the saturated one is too intense, maybe we should tweak it a bit?-
@pedroms I'm looking into a third alternative. I don't have any strong candidates, but I wanted to post an update here.
@cperessini Ok, thanks for letting us know
Reassigned to @awhildy
Reassigned to @cperessini
-
I agree with @pedroms here. I prefer
#005299because there is visible difference between the link color and the hover color. If there isn't a strong candidate for a third option (and I don't think there needs to be), I would vote to go with#005299.Edited by Taurie Davis -
@tauriedavis Agree. After taking a break from looking at these colors every day, I can now see that
#005299is good. I'll update the issue with the final decision. mentioned in issue #25419 (closed)
changed milestone to %8.16
added Deliverable and removed ~131895 labels
-
@lbennett: I believe you are working on this (along with #24129 (moved) and #24125 (moved)) for 8.16. Let me know if you have any questions about the design for these issues. Thanks!
Edited by username-removed-711361 
@awhildy I will be! This is going to be an interesting adventure into the depths of our css, it could either be really simple or really tough.
-
@cperessini Should the final design state that all these anchors should have an underline on hover as well?
-
@tauriedavis That's part of #24129 (moved), but @lbennett might want to combine the effort for the two?
created branch
24130-add-color-change-on-hover-for-all-anchorsmentioned in merge request !8394
added to schedule and removed Deliverable labels
@lbennett Are you still working on this?
-
@jivanvl !8394 was pretty much done AFAIK, in review.
/cc @cperessini
added Deliverable label
changed milestone to %9.4
assigned to @lbennett
changed milestone to %9.5
removed Deliverable label
mentioned in issue gitlab#6850
moved to gitlab#6868
Hey!
GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current
gitlab-cerepository will become a read-only mirror, without any proprietary code. All development is moved to the currentgitlab-eerepository, which we will rename to justgitlabin the coming weeks. As part of this migration, issues will be moved to the currentgitlab-eeproject.If you have any questions about all of this, please ask them in our dedicated FAQ issue.
https://gitlab.com/gitlab-org/gitlab-ee/issues/13855You can also find more information here:
https://gitlab.com/gitlab-org/gitlab-ee/issues/13304- https://about.gitlab.com/2019/08/23/a-single-codebase-for-gitlab-community-and-enterprise-edition/
Frequently Asked Questions
For an up to date list of questions and answers, please take a look at
https://gitlab.com/gitlab-org/gitlab-ee/issues/13855What will we do with the repository names?
https://gitlab.com/gitlab-org/gitlab-ee/ will become https://gitlab.com/gitlab-org/gitlab, and https://gitlab.com/gitlab-org/gitlab-ce will become https://gitlab.com/gitlab-org/gitlab-foss.
Why rename gitlab-ce to gitlab-foss?
Using "gitlab" and "gitlab-ce" would be confusing, so we decided to rename gitlab-ce to gitlab-foss to make the purpose of this FOSS repository more clear
I created a merge requests for CE, and this got closed. What do I need to do?
You will need to create a merge request at https://gitlab.com/gitlab-org/gitlab-ee/. This link will eventually redirect to https://gitlab.com/gitlab-org/gitlab.
How does the licensing work in this new setup?
Everything in the
ee/directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in theee/directory, the process of contributing changes is the same as when using the gitlab-ce repository.Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed?
No. Merge requests submitted to this project will be closed automatically.
Will I still be able to view old issues and merge requests in gitlab-ce/gitlab-foss?
Yes.
How will this affect users of GitLab CE using Omnibus?
No changes will be necessary, as the packages built remain the same.
How will this affect users of GitLab CE that build from source?
Once the project has been renamed, you will need to change your Git remotes to use this new URL. GitLab will take care of redirecting Git operations so there is no hard deadline, but we recommend doing this as soon as the projects have been renamed.
Where can I see a timeline of the remaining steps?
https://gitlab.com/gitlab-org/gitlab-ee/issues/13304Will community contributions submitted to the new "gitlab" repository be available in the new gitlab-foss repository?
Yes, these changes will be synced to gitlab-foss automatically, several times per day.
