Was able to reproduce this on the Codex docs site, but it seems to be a browser bug.
When I uncheck the background-color property on the span carrying the check mark, while I'm inspecting the element, I can make the check mark appear again.

Assigning to you @bmartinezcalvo for the last piece, updating the component in the Codex Figma library.

While not completed mandatory fields are the most common case for erroneous feedback, error states could also apply to non-mandatory field, for example in an inline validation, where a Combobox would have to include a certain pre-given or pattern-following value (think only letters versus other chars like special characters).

Turns out the change to rems was the origin of the wrongly rendered icon.

I was going for showVerticalBorders as it seems closer to comparable props like showDividers in Dialog.

@bmartinezcalvo This task currently says rest of the form components, but names only TextArea and Select right now. Combobox, Radio etc. are also missing.

So this was stated so far as mainly about TextInput, but equivalent this change should also cover TextArea.
And then we already got a third and a forth error border style in place: Select and Checkbox. While latter already features the same logic, Select would be untouched right now when in error state.
In my opinion providing the same error hover border feedback would make sense on Select.

I've shared my minor concern about if a reset button might be a useful usability feature in certain contexts of MediaWiki consumers outside. But I'll go ahead with the removal of the functionality.

Note to myself: Where does styles like kbd fit in a public Codex typography mixin? See T358861 for context.

I've just shared on a vertical spacing question for Fields in Codex, but aimed for a general approach, that might be something worth to consider here as well.

It's from the FlaggedRevision extension.

Another example to be amended:

I agree with your statement @DTorsani-WMF. Would you make a proposal (with my help in testing on Special:Block, as already shared we had somewhat arbitray 50em on OOUI) and discuss it in next design sync?

A decision here might also affect Dialog button spacing.

With call for help by collaboration-services team… :)

Do we really need a name prop for ToggleSwitches?
In my understanding they should never be connected even though they are a hidden checkbox under the hood.

@lwatson @Catrope Should this be child of the EPIC or did we want to separate those follow-ups out?