Add Block: Search

[melchoyce]

Attributes

• Display search icon

States

Selected:

Neutral:

---

Question:

• I added "Display search icon," but should that be a theme decision, not a user decision?

[StaggerLeee]

I hope all those native "widgets" in editor will be hidden on default. Or easy hidden with code.

With them I cannot say anymore to beginners Users, just go ahead in backend, you cannot ruin layout, design, or website, zero chance.
I set backend in an way they cannot ruin anything, even if they tried it by purpose. (Generally speaking about Editor role)

[paulwilde]

I added "Display search icon," but should that be a theme decision, not a user decision?

I believe it should be up to the theme in this case, and the option could be added by extending this particular block should the theme author choose to do so.

[afercia]

Ideally, placeholders should not be used as replacement for labels, see https://core.trac.wordpress.org/ticket/40331 especially in complex forms with several fields.

We've discussed this issue a few times in the accessibility team and agreed it could be acceptable to use a placeholder as in the "Neutral" mockup above for single form fields with a very specific task to accomplish. Even in this case, the search field will need a visually hidden label because the placeholder is going to not contribute any longer to the computation of the accessible name.

[melchoyce]

Thanks for the feedback — I'll work on an update.

[karmatosed]

I would say the search icon should be down to the theme, I am not sure about it as a user decision. My vote would be to let themes decide that.

[melchoyce]

Updated to remove the search icon option, and add an editable label and placeholder:

Thinking the label should be "Search" by default, but still editable. The placeholder can default to empty, unless someone clicks in to add one. Does this work better?

[karmatosed]

As the project moves towards merge proposal, we are moving issues that aren't needed for that to projects. This doesn't mean they won't get done, they totally can and that's why we're moving to projects. This allows us to focus on the issues that have to happen to Gutenberg. I am closing this but it will live in projects.

[melchoyce]

Updated mockup:

[danielbachhuber]

Copying @westonruter's comment from #4501 (review):

It's a difficult question on whether to try to re-use get_search_form(). I think the most important thing is that the preview be faithful to the frontend. This is currently a challenge in Gutenberg for widgets because they have separate implementations between editing (JS) and viewing (PHP). A theme can override the PHP rendering to be something completely different already, which would break the WYSIWYG block editing preview. But this would be less likely than the theme defining a searchform.php. Since the block here is not going to be used in normal theme template contexts but rather in new Gutenberg contexts, I'm inclined to think that the search block you're defining here should break away from trying to re-use searchform.php to instead use a new Gutenberg block template, one that leverages all of the new customizability you are introducing. After all, the Latest Posts widget block is not re-using the Recent Posts widget template.

In the Gutenberg world, theme templates are going to need to be rethought anyway in favor of a block templating system, I think. (Especially to eliminate duplicating templates across PHP and JS.) So I don't think we should try too hard here to re-use existing WP theme templates.

[gibrown]

The top search on wp.com is for "", and the second top is for "search". This occurs because users often click the search button rather than type something into the box first.

There is an unmerged patch for this in https://core.trac.wordpress.org/ticket/34886 that we should fix as a part of this.