Ben Dwyer

We are already overriding these styles in the individual components, so this doesn't break that convention any more than it's already been broken, it just centralizes that code.

> @scruffian I think that's reasonable. Please note that the first example in the description has an intentional design detail where the tabs indicator overlaps the border below it, as...

I have updated this based on the feedback above. I have made it a locked component to give us time to iterate on it. > After this is merged, can...

I'm going to merge this so that we can continue to align the various panels to use this component and ensure that improvments are made to all at once. I...

Also cc @aristath as he's been looking at form things.

~I think a list of included or excluded types is going to be long. My preference is probably just to simplify the selector to all inputs, except buttons.~ Actually on...

Updated to use this selector: `textarea, input:where([type=email],[type=number],[type=password],[type=search],[type=tel],[type=text],[type=tel],[type=url])`

@meerhimmel thanks for the feedback. What if each type of input had its own element, so we'd have this: ``` "text": ".wp-element-text", "url": ".wp-element-url", "email": ".wp-element-email" "number": ".wp-element-number", "range": ".wp-element-range",...

> Whats currently blocking this PR? Lack of agreement about whether this is the right approach. I suggest we take it off the 6.5 board.

> What is needed to solve this for 6.7? Some agreement about the selectors to use. Should we target all inputs, or only specific types?