-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Unify the search fields #56388
Comments
I don't know that the visual DNA of a search input needs to differ from any other input type. So I'd lean towards the fonts approach (with the icon on the left) rather than the Inserter one here. @ciampo what's the best way to proceed here? Could |
I can look into rewriting |
I think this is ok, the container would have to be extremely narrow for this to be an issue. Generally icons found at the right of an input are interactive (e.g. clear text, show password, dictate), while icons on the left are more decorative. Since the current design violates that heuristic the trade-off seems worth it. |
Related to this issue, what do you think about completely removing the gray background color or making it a lighter gray? As I recall, I may have seen an issue somewhere that mentioned this gray background color. The current placeholder text color uses the browser's user agent style. In my environment it is If we assume the background color is white, the contrast ratio should be |
In the vast majority of cases I see no reason for SearchControl do differ significantly from any other text field. |
Regarding the background color, I investigated why it was applied only to this component:
|
Perhaps the next step here is to open issues with updated design specs for |
Description
In a few places in the editor, a 'Search' field is in use. There are a few occurrences that are largely inconsistent, both visually and in terms of labelling, semantics, usage of the placeholder.
I'm not sure why there's such inconsistency. To me, it makes sense to establish a well defined pattern that is the best for visuals, usability, accessibility, and then reuse that pattern where necessary. Instead, having serch fields that look all differentand are labelled inconsistently doesn't help user experience and adds unnecessary cognitive load.
A few examples:
In the Patterns explorer modal dialog:
In the (so far experimental) Dataviews > pages:
In the Fonts modal dialog:
@WordPress/gutenberg-design I'd think this is a good case to add to the design system documentation, see #53615. That would help contributors to this project to be trained and educated to re-use existing, established, patterns instead of introducing inconsistent ones.
Step-by-step reproduction instructions
Aa
icon button) > Install FontsScreenshots, screen recording, code snippet
No response
Environment info
No response
Please confirm that you have searched existing issues in the repo.
Yes
Please confirm that you have tested with all plugins deactivated except Gutenberg.
Yes
The text was updated successfully, but these errors were encountered: