I'm particularly looking for feedback on whether folks think the new euiFormControlStyles() JS mixin feels DRY enough compared to the previous Sass mixin or if they like that it's slightly more verbose but also more explicit.

Previously there were no options in the Sass mixin to exclude certain selectors etc, and I think this newer approach is more repetitive but easier to mix and match custom CSS per-component.

I personally like the new euiFormControlStyles() way 👍
And when it comes to complex styles like forms, I think a bit more verbosity in defining the styles more specifically per usage is not a bad thing as - imho - it helps to understand what styles are added more explicitly.

E.g. redefining this following part might look unnecessary and could be dried out but it also:
a) makes more clear what's really used - it's being deliberate about what to use
b) shows that it's the default
c) provides the styles definition with the component instead of at a higher level

&:focus {
  ${formStyles.focus}
}
&:disabled {
  ${formStyles.disabled}
}
&[readOnly] {
  ${formStyles.readOnly}
}
&:autofill {
  ${formStyles.autoFill}
}

That was what I was thinking as well, thanks a million for your thoughts Lene! I think not defining the selectors also gives us more flexibility with them for one-offs, e.g. if we wanted :focus-visible as well as :focus for one specific selector, and so on and so forth.

I personally like the new euiFormControlStyles() way 👍
And when it comes to complex styles like forms, I think a bit more verbosity in defining the styles more specifically per usage is not a bad thing as - imho - it helps to understand what styles are added more explicitly.

E.g. redefining this following part might look unnecessary and could be dried out but it also:
a) makes more clear what's really used - it's being deliberate about what to use
b) shows that it's the default
c) provides the styles definition with the component instead of at a higher level

&:focus {
  ${formStyles.focus}
}
&:disabled {
  ${formStyles.disabled}
}
&[readOnly] {
  ${formStyles.readOnly}
}
&:autofill {
  ${formStyles.autoFill}
}

That's a helpful comment! ❤️

It's a neat technique I can't believe I only just discovered this late into the conversion! 💀

Just to be sure it's expected currently: I noticed that the spacing changes slightly between icons and value. We changed the approach to position icons and calculate the affordance - so I assume this is expected? 🙂

Responding to Tomasz as well here for comment threading.

EuiFieldSearch and EuiFieldPassword have a smaller icon padding now (see screenshot)

Expected/known change, that "decision" was made in #7770 when the CSS variable technique was adopted. I opted to greatly simplified the calculated logic over fussing with a few pixels or so, what I primarily care about is that text is rendering/cut off appropriately relative to the number of displayed icons.

All fields have very slightly darker backgrounds (#fbfcfd on main and #f9fbfd on this branch). I actually like that they're darker 🤔

Some amount of intentional-ish color changes are also being made in the Emotion conversions (mostly around borders/backgrounds). Some of that is the baseline color tokens were adjusted by Caroline at the beginning of the Emotion conversion, and some of that is intentionally reducing complex color calculations in favor of performance. In general unless something is failing color contrast checks or looks very obviously wrong/different to the naked eye, I'm not fussed about a slight color diffs.

Actually, hm, I may have spoken too soon on that first paragraph. Now that I flip back and forth between the old and new I'm not sure I super love the direction the padding is offset in, so let me try to tweak the numbers a bit

I can't get the numbers any better without some pretty ludicrous math. Going to leave it for now and maybe come back to it at the end of the conversion. The paddings are different but not broken looking, so IMO it's Good Enough 😅

That seems reasonable to me too! 👍