Gutenberg: Expand Search block customization

[mtias]

The search block is currently very rough to use as a design element on a theme or navigation design. It currently renders like this:

This block should have some options in its attributes to:

• [x] Not render a visible label. (@apeatling) https://github.com/WordPress/gutenberg/pull/24666
• [x] Allow rendering a magnifying glass icon and use it as the submit button. (@apeatling) https://github.com/WordPress/gutenberg/pull/24666
• [x] Allow not having the submit button visible. (@apeatling) https://github.com/WordPress/gutenberg/pull/24666
• [ ] Control over border radii. (@apeatling) https://github.com/WordPress/gutenberg/pull/25203
• [ ] Control over padding. (@apeatling)
• [ ] Control over background color.
• [ ] Control over text color.
• [ ] Control over border color.
• [ ] Ability to render search interface as a full-screen overlay (and other treatments).
• [ ] Allow expanding the field on focus.

Some of these could be built as variations offered when inserting the block (in the placeholder scope).

[mapk]

I've made a first pass at some iterations. Still working, but wanted to share what I had for today.

1. I improved the block to match G2 iterations.
2. Settings:
   a. Show/hide button
   b. Use icon instead of text in button
   c. Place button inside field instead of outside field
   d. Show/hide label
   e. Adjust border radius of field. (I'm thinking the button would inherit the theme styles) Doing this keeps the settings simplified more.
   f. Adjust border color
3. Block styles:
   a. Default – What you see.
   b. Expanding – A version that expands on focus.

We can probably add a lot more settings to allow more control, but I'm attempting to start out simple. I'll work on revisions tomorrow.

Prototype

https://www.figma.com/proto/TvjAY5aNMMM8boPHPNwGpT/Search-block?node-id=1%3A329&viewport=-973%2C287%2C0.5&scaling=min-zoom

Mockup

https://www.figma.com/file/TvjAY5aNMMM8boPHPNwGpT/Search-block?node-id=1%3A329

[mtias]

What elements (if any) do you think could be added to the toolbar?

[karmatosed]

Interesting explorations @mapk. I tend to agree with @mtias that considering what could be added to toolbar might be interesting.

One thing worth noting is we currently have these:

Whilst having uniform interactions is good, I am not convinced if all of these are needed for this block. In my explorations I removed a lot, however, I don't believe that will be the end case so examining each is a good idea.

In exploring this more, I think with the padding work being done on other blocks we can move that out of any menu, so I dropped that.

There is prior art for text and background colors, we could just add border to:

Where we have options like showing button and also an icon, I do wonder if those are style variations? It feels like that could avoid having too many options here. I wonder if by using only style variations and styling in toolbar, could we get all of these options? How many need to still be in sidebar?

As far as border-radius is concerned, I think exploring what that could be in the toolbar could be interesting. For example, there is a pattern with text/background color to follow. Here is a really rough mock of that potential.

All of these aren't complete, but hopefully, they add some fuel to your mocks for the next iteration phase.

[mtias]

These are not rich-text inline options, they should not show up in the dropdown arrow but in the main toolbar, before "bold" etc.

[iamtakashi]

Some sketches to illustrate what the user might want to achieve:

As @mtias mentioned above, it's often to see a search in a full or partial overlay that appears by clicking an icon. I tried to illustrate an example with below.

[karmatosed]

An iteration with the note on text tools. I did move out the background / text color as it now has border combined. Again, the icons and ideas are all fuel over complete.

[tomtev]

Love all you have done, but styling should be done by themes or plugins?
IMO core blocks should only have options like "Show button", "Show label" etc, but styling should be done by themes.

[mapk]

My goal for this block is to achieve common search interfaces without an overwhelming amount of settings. As a Core block, I'd like to keep it somewhat limited and allow detailed styles to be applied by the theme.

@iamtakashi, your mockups above are beautiful and highlight the many variations of search forms. Thank you! However, I'd like to start out with a simpler set of options like this:

These variations alone include a large number of settings already. But ultimately, taking into consideration the issue's outline, we can edit:

• Border & background colors
• Border radius
• Icon or button, or no button
• Label, placeholder, and button text edits
• Show or hide label
• Icon display inside search field
• [not seen] Search overlay option

These particular examples do not include settings for:

• Padding
• Spacing
• Border width
• Text color

---

@karmatosed has done some great explorations to bring settings to the block toolbar – Thanks!

Initially, the complexity of tabs inside the toolbar popover felt too overwhelming, especially when we consider that Border color can include border colors for both the input field and the button. Background color can include background colors for the input field and the button too. And finally, if we choose to allow text color edits, this can include the text color for the label and the button. So quickly these settings multiply. This is why in my note above, I've excluded text color edits for the initial MVP.

What elements (if any) do you think could be added to the toolbar?

So now, with all these settings, which do we display in the top toolbar that are both important and easy to interact with?

My first goto for important and easy settings are:

• Text or icon button.
• Placement of button inside or outside of input field.

Here's where I landed today:

All of this is experimentation. I'm not quite solid on any of it yet. These can very well just be style variations. I'm still working in the same Figma file.

[mtias]

@tomtev that's generally the case, yes, but note that blocks also need a default in case a theme has not specified styles for a block (particularly for 3rd party blocks). That's why some of these are being defined as attributes of the block with the expectations themes will set the default attributes based on their design requirements. Right now that exists in a theme.scss split file that is opt in through add_theme_support. A larger overview of how all these pieces need to fit in is here: https://github.com/WordPress/gutenberg/issues/20331

[gibrown]

The pattern of using a search icon that then unhides a search box is very common and should be supported by Core. The search box should maybe even default to this behavior when on mobile. 2020 for instance uses this pattern.

[apeatling]

In #24666 I've started work on the options for labels and button position. The UI is currently an odd hybrid of the above, but I hope having something to try moves the conversation forward and we can get the UI to a good and final place.

[gibrown]

I tried adding the search block into a page recently and one issue I had was the width and having no control over the width of the search box. This feels like an important thing for the end user to be able to control rather than leaving it to the theme.

Another thought is control over a button vs a search box depending on whether the visitor is on a mobile device or not. A common approach is that on desktop the site may have a full search box, but on mobile it is just a button.

[apeatling]

Reopening this because it was only partly completed in #24666.