feat: add search box spec

[eljefe223]

Pull Request

📖 Description

Adds search box spec

🎫 Issues

Addresses: #4967

👩‍💻 Reviewer Notes

📑 Test Plan

✅ Checklist

General

• I have included a change request file using $ yarn change
• I have added tests for my changes.
• I have tested my changes.
• I have updated the project documentation to reflect my changes.
• I have read the CONTRIBUTING documentation and followed the standards for this project.

Component-specific

• I have added a new component
• I have modified an existing component
• I have updated the definition file
• I have updated the configuration file

⏭ Next Steps

[chrisdholt]

I think we have an issue out for whether or not we should include labels on form elements - would be good to look at that prior to finalizing this component.

[eljefe223]

TextField and TextArea both have them. Even though its not a common design pattern there may be cases where we want a label.

[chrisdholt]

Sure, I'm aware of the prior implementation - I think there is a larger discussion to have here though as some form elements include this and others do not. One of the primary issues we've seen is associating across the light and shadow DOM. There are a couple proposals out there being made, but nothing exists now to solve the problem. Right now we aren't consistent and there are issues with the current approach from an accessibility standpoint. The question I think we have to ask is what is our best path forward as of now with regards to components including labels. How far out is any solution? Is the label part of the control or is it better off as part of a "form-field" component? If "it depends", is there a clear line for when we would and would not include a label as part of a component?

[chrisdholt]

Here's an example of something recently proposed for a platform enhancement to help with this, but again - it doesn't yet exist. Regardless of what is coming, I think the question above in regard to the components themselves likely needs to be answered for what our path forward is.

[eljefe223]

Whatever we do we should be consistent, if its possible to separate the label in the form of of a form-field component that seems like a more flexible approach.

[chrisdholt]

could this just be slotted in end or does it require it's own slot?

[eljefe223]

I think we do. What about cases where we would want a button to the right of the input that executes the search?

[chrisdholt]

We aren't limited to one slotted element per slot, I'm primarily curious of how common the clear selection is and how difficult it is to wire up something without it's own slot. Is it prohibitive or just preferred because it seems easier? There's no right or wrong answer here, but it seems like we're providing a pretty specific slot for a specific implementation. More research to point to this being consistent enough that it should have a unique and custom slot just for this behavior. If we don't need to wire up any behavior to the clear button by default and there's nothing prohibitive, I'm just curious about how much value the unique slot provides.

[eljefe223]

The clear button is the defaulted in the react fluent controls. It is also a common pattern across many search box examples. Perhaps we just provide a slot for the glyph inside the button, The functionality is directly tied to the input so slotted the whole button makes less sense.

OR we just slot in any number of after content and the clear button can be one of them. It would just be on the author to wire up the clear functionality.

[chrisdholt]

I don't particularly care about specific implementations such as how the Fluent React controls are built out - I'm primarily concerned right now with gather requirements and then determining what gets first-party support. Our goal should be to enable a majority of use cases, I don't think that always requires us to prioritize all use cases with first-party API support.

If the above is under consideration (baking a button into search), I think we need more research and examples of that being the most common use case. I think we'll find that it's a use case, but not necessarily the most common. The next thing that comes to my mind are, "what are the implications of baking a control in like that"? We don't follow that pattern anywhere else, so it would be new. What possible draw backs exist? I have a few questions that immediately come to mind - how do I bind click events, keyboard events, etc to the default button that are unique to my implementation? How do we handle scenarios where a user wants to add telemetry to the default button? Defaulting interactive controls in the shadow DOM isn't a pattern we typically have and I think we need more research than what I see here to determine that as the right and intuitive course of action.

[litteredwitherrors]

Possible assumptions about a clear feature:

• Always related to presentation
• "Clear" is always presented as a glyph
• The slotted element is focusable (A11y implications)
• Search specifically needs clear as opposed to all input fields.
• Always a web search

[litteredwitherrors]

Possible assumptions about a clear feature:

• Always related to presentation
• "Clear" is always presented as a glyph
• The slotted element is focusable (A11y implications)
• Search specifically needs clear as opposed to all input fields.
• Always a web search

[EisenbergEffect]

Can this be closed?

[EisenbergEffect]

Seems that we already merged the component. Does this spec match what was implemented and can we merge it?

[EisenbergEffect]

We should probably have both change and input events here.

[chrisdholt]

Seems that we already merged the component. Does this spec match what was implemented and can we merge it?

@eljefe223 can you make sure this is up to date and reflects where we currently are? Ideally we ensure these are merged before the component work is done :)

[awentzel]

nit: --- seems out of place or unnecessary here.