Make WordPress Core

Opened 4 years ago

Closed 4 years ago

#56573 closed defect (bug) (fixed)

Twenty Nineteen: Search Button hover color issue

Reported by: tahmidulkarim Owned by: audrasjb
Priority: normal Milestone: 6.1
Component: Bundled Theme Version: 5.9
Severity: normal Keywords: has-patch has-screenshots close
Cc: Focuses: accessibility, css

Description

In Twenty Nineteen theme, the search button at the bottom has inconsistent text color in hover state.

Steps to replicate:
1: Activate the Twenty Nineteen Theme
2: View the Front page and scroll to the bottom upto the search box
3: Hover on the Search button

For better understanding, I have attached a screenshot.

Attachments (1)

Screenshot at Sep 15 12-10-08.png (734.3 KB ) - added by tahmidulkarim 4 years ago.

Download all attachments as: .zip

Change History (16)

#1 @audrasjb
4 years ago

  • Focuses accessibility added
  • Keywords needs-design-feedback removed
  • Milestone Awaiting Review6.1
  • Version 6.0.2

Hello, welcome back to WordPress Trac,

Indeed, this is something we should fix.
Adding accessibility focus and moving to 6.1.

#2 @audrasjb
4 years ago

  • Owner set to audrasjb
  • Status newaccepted

Using color: #fff; on focus and hover states would fix the issue.

This ticket was mentioned in PR #3257 on WordPress/wordpress-develop by tahmid-ul.


4 years ago
#3

  • Keywords has-patch added; needs-patch removed

Trac Ticket - https://core.trac.wordpress.org/ticket/56573

Fixed the hover color issue on the search button.

Added a variable with the value to set color #fff on button text when hovered.

#4 @tahmidulkarim
4 years ago

@audrasjb, instead of adding the color: #fff; directly in the hover and focus states, I have created a CSS variable with the name $color__text-button-hover where the color code (#fff) is stored and then used that variable in the hover and focus state. This keeps the CSS style consistent with the other styles.

#5 @krupalpanchal
4 years ago

  • Keywords has-screenshots added

Hi, there.

I think just for that one button to create a variable of color is not good. Because if we are using the variable for CSS then we must use it globally, I mean everywhere in the CSS file. Otherwise, at some places, there will be a #fff and at some places will be a variable.

Anyone give your suggestion.

#6 @robinwpdeveloper
4 years ago

I think color: #fff should do the trick.
Using variable is not necessary here since variables are mostly for global scope.

#7 @tahmidulkarim
4 years ago

Adding color: #fff directly will indeed make it more simpler. But, the reason I created a variable was to keep the overall styles consistent, as all the other color properties are set using variables. Anyway, let's see what @audrasjb thinks about that.

Last edited 4 years ago by tahmidulkarim (previous) (diff)

This ticket was mentioned in Slack in #accessibility by sabernhardt. View the logs.


4 years ago

#9 @sabernhardt
4 years ago

In case it makes a difference, the screenshot displays the Search block (with the button outside), not the legacy Search widget.

#10 follow-up: @poena
4 years ago

I am not able to reproduce the original issue in WordPress 6.1 alpha.
The button has a blue background and white text, and black background and white text on hover in my test.

Viewing the source, the element does inherit the correct white text color from the button styles.

#11 in reply to: ↑ 10 @sabernhardt
4 years ago

  • Focuses css added

Replying to poena:

I am not able to reproduce the original issue in WordPress 6.1 alpha.

I did not experience it at first either, but it happened when I tested in WordPress 6.0 and deactivated the Gutenberg plugin.

The search block's button had its own text and background colors until GB41822.

#12 @poena
4 years ago

Then is it enough that this is solved in 6.1, or is the expectation that the theme should be patched to cover for the 6.0 core issue?

#13 @audrasjb
4 years ago

  • Keywords close added

I think we're good if it is solved in 6.1.

We can probably close this as Fixed :)

This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.


4 years ago

#15 @joedolson
4 years ago

  • Resolutionfixed
  • Status acceptedclosed
  • Version5.9

It looks like this problem was caused by styles in an older version of the block editor, and has already been resolved. Closing as fixed upstream. Was introduced in 5.9.

Note: See TracTickets for help on using tickets.