[input] Update ref type to HTMLElement

[mj12albert]

This allows <Field.Control render={<textarea />} /> without type errors when passing a ref to a HTMLTextAreaElement

• I have followed (at least) the PR section of the contributing guide.

[pkg-pr-new]

• base-ui-tanstack-start

• vite-css-base-ui-example

  pnpm add https://pkg.pr.new/mui/base-ui/@base-ui/react@3866
  

  pnpm add https://pkg.pr.new/mui/base-ui/@base-ui/utils@3866
  

commit: 050410d

[mui-bot]

Bundle size report

Bundle	Parsed size	Gzip size
@base-ui/react	0B(0.00%)	0B(0.00%)

Details of bundle changes

---

Check out the code infra dashboard for more information about this PR.

[netlify]

✅ Deploy Preview for base-ui ready!

Name	Link
🔨 Latest commit	050410d
🔍 Latest deploy log	https://app.netlify.com/projects/base-ui/deploys/6979c9fc032ccd0009ae6443
😎 Deploy Preview	https://deploy-preview-3866--base-ui.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[greptile-apps]

Greptile Overview

Greptile Summary

Updated ref types from HTMLInputElement to HTMLElement in FieldControl and Input components to support <textarea /> elements via the render prop.

Key Changes

• FieldControl and Input now accept React.ForwardedRef<HTMLElement> instead of React.ForwardedRef<HTMLInputElement>
• Added spec files demonstrating type-checking for textarea and contentEditable elements

Issues Found

• The contentEditable example in FieldControl.spec.tsx:9-11 will cause runtime errors because the validation system expects elements with .validity, .validationMessage, and .setCustomValidity() methods, which plain HTMLElement doesn't have
• Internal type mismatch: validation.inputRef is still typed as React.RefObject<HTMLInputElement | null> in useFieldValidation.ts:59, creating a type inconsistency with the broadened ref type

Confidence Score: 3/5

• This PR introduces a type mismatch that allows invalid element types, though the primary use case (textarea) works correctly
• While the change successfully enables <textarea /> support (the stated goal), the broader HTMLElement type allows contentEditable divs that will crash at runtime when validation occurs. The internal validation system still expects HTMLInputElement properties.
• Pay close attention to FieldControl.spec.tsx - the contentEditable example needs removal or the validation system needs updates to support it

Important Files Changed

Filename	Overview
packages/react/src/field/control/FieldControl.tsx	Updated ref type from HTMLInputElement to HTMLElement, enabling textarea support but introducing type mismatch with internal validation system
packages/react/src/input/Input.tsx	Updated ref type from HTMLInputElement to HTMLElement to match FieldControl changes
packages/react/src/field/control/FieldControl.spec.tsx	Added type-checking tests for textarea and contentEditable elements, but contentEditable will fail at runtime
packages/react/src/input/Input.spec.tsx	Added type-checking test for textarea element (valid use case)

[greptile-apps]

_{1 file reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

[LukasTy]

Wouldn't this be more correct?

Suggested change

	forwardedRef: React.ForwardedRef<HTMLElement>,
	forwardedRef: React.ForwardedRef<HTMLInputElement | HTMLTextAreaElement>,

Could also update specs with testing both versions.

[mj12albert]

I think it could actually support <div contentEditable>

The contentEditable example in FieldControl.spec.tsx:9-11 will cause runtime errors because the validation system expects elements with .validity

Regarding this comment from the bot, I don't think it really matters because TS would reject validation props passed to a div anyway?

[LukasTy]

Yeah, good point, we can keep the added flexibility.
In any case, the user needs to define the actual type that they are passing to the component.

One minor gripe is that the default ref type (without any explicit render) is going to become more generic, even hough we know that it renders an <input>

[LukasTy]

Yeah, good point, we can keep the added flexibility.
In any case, the user needs to define the actual type that they are passing to the component.

One minor gripe is that the default ref type (without any explicit render) is going to become more generic, even hough we know that it renders an <input>