Remove outdated multiline single-side border caveat from TextInput docs

[theprantadutta]

Fixes #5151

The TextInput page states:

Additionally, border styles that apply to only one side of the element (e.g., borderBottomColor, borderLeftWidth, etc.) will not be applied if multiline=true. To achieve the same effect, you can wrap your TextInput in a View:

This removes that sentence. Two separate problems with it:

1. The workaround it promises is never shown. The sentence ends in a colon introducing the example below it, but that example is a plain multiline TextInput styled with borderColor / borderWidth — an all-sides border, applied directly to the TextInput, with no wrapping View anywhere. So the text promises a demonstration the example does not contain, regardless of whether the limitation itself is still real. This part needs no runtime check to confirm; it's visible in the page as it stands.

2. The limitation looks outdated. It came in with the original "Known issues" section in #649 (December 2018), well before the New Architecture reworked border rendering. On Android today, ReactEditText — the view backing TextInput, multiline included — applies borders through the same per-edge path as any other view:

public fun setBorderWidth(position: Int, width: Float) {
  setBorderWidth(this, LogicalEdge.entries[position], toDIPFromPixel(width))
}

That's BackgroundStyleApplicator.setBorderWidth, taking a LogicalEdge, and there is no multiline special-casing in the applicator. The reporter of #5151 also tested single-side borders on a multiline input in Snack across Android, iOS, and Web and found they applied as expected.

What I could not verify

I want to be straight about this rather than imply more than I did: I did not run a Snack myself. I don't have an Android SDK on this machine, so points above are source-level reading plus the reporter's testing, not my own end-to-end run on a current release.

If you'd like empirical confirmation before merging, that's completely fair — either the reporter can share their Snack, or I'm happy to have this sit until someone can check it on a device. Problem 1 stands on its own either way, so if you'd rather keep a corrected version of the limitation note, I can instead reword it and add an example that actually demonstrates the wrapping-View workaround. Just say which you prefer.

I've edited only docs/textinput.md and left the versioned copies under website/versioned_docs/ alone, since those describe released versions.

For disclosure: I use an AI assistant in my work, and I review and verify everything before it goes out.

[Simek]

Hey @theprantadutta, thanks for picking it up and providing a bit more context.

I was able to verify that the border styles are applied correctly to multiline text inputs on hardware device for both platforms using Expo SDK 54, so React Native 0.81, using this Snack example:

• https://snack.expo.dev/@simek/multline-text-input

Can you also update all versioned docs, starting from 0.81 onwards? The doc files are located here:

• https://github.com/react/react-native-website/tree/main/website/versioned_docs

[theprantadutta]

Thanks for verifying it on a device — that's the part I couldn't do myself, so I appreciate you closing that gap.

Done: the caveat is now removed from docs/textinput.md plus every versioned copy from 0.81 through 0.87, one line each.

One note on the history of this branch: my fork was a few commits behind and version-0.87 didn't exist at that point, so my first attempt added it as a new file instead of editing it. I've dropped that, synced with main, and redone the 0.87 edit against the current file — the PR is now 8 files at +1/-1 each.

[Simek]

Thanks for the follow up updates and the context! 👍