<textarea> should support the [pattern] attribute like the <input> element

[Gambloide]

The input [pattern] attribute should be usable with <textarea> as well, equivalent to:
https://html.spec.whatwg.org/multipage/input.html#the-pattern-attribute

<textarea> supports [minlength] and [maxlength] but sometimes that is not enough.
For example: sometimes one may want to limit available characters in <textarea> to letters-only.

Original issue from w3c by @soanvig: w3c/html#1028

[zcorpan]

Can you give concrete examples of where this would be useful?

[soanvig]

@zcorpan there is simply no reason for it to be not implemented to be honest. I don't remember my original case - this issue is 6 years old. I guess that I really didn't want to have any numbers or special characters in the textarea, but for what bizzare reason I have no idea. Maybe I was using textarea just like an input, but used some of it's special behaviors to achieve some end-result. Probably I was hacking something.

[zcorpan]

We generally don't add features without knowing that they're useful for something. See https://whatwg.org/faq#adding-new-features in particular step 2.

[lionel-rowe]

Can you give concrete examples of where this would be useful?

Anywhere you want to allow the user to input a list of items, one item per line, where each item can be matched against a specified regex. For example, assuming {{url}} is a regex fragment that matches a URL, you could specify pattern="(?:{{url}}\n)*(?:{{url}})?" to match zero-to-many newline-delimited URLs, with an optional trailing newline. This would be useful for specifying block lists/allow lists.

Other common use cases would be newline-delimited lists of emails, usernames, file hashes, IP addresses, etc.

[Gambloide]

The use case which triggered me to look into this is a <form> allowing users to provide long text with 100+ characters. However, it comes with limitations on the characters to be used, introduced by a 3rd party API which is supposed to consume the content.

An <input> field quickly becomes to small to see all the input at the same time and makes it cumbersome to edit, hence <textarea> is the only valid <form> element to use in this instance. From the point of view of a user, <textarea> is just an <input> with flexible size and support for newlines anyway.

When I insert content into a form as a user, I expect it to tell me if I am doing something unsupported and guide me on how to correct my content, the type of form element does not matter.

Currently, everyone has to work around this by manually implementing client-side validation in Javascript in an attempt to imitate the existing validation of <input>. This is also what I see in frameworks dealing with <form> validation and generation. I asked myself "Why is this necessary?" and I don't see a good reason, hence why I opened this topic.

[zcorpan]

Thanks. Can you link to any live sites that are working around the lack of this feature with JS?

For example, assuming {{url}} is a regex fragment that matches a URL, you could specify pattern="(?:{{url}}\n)*(?:{{url}})?" to match zero-to-many newline-delimited URLs, with an optional trailing newline. This would be useful for specifying block lists/allow lists.

Maybe <input type=url multiple> should be a thing to enter multiple URLs (it could render as multiline, possibly)? This would both be more user-friendly in that users can choose URLs without having to type or copy-paste, and better DX because you don't need to come up with (or copy-paste) a correct regexp for URLs.

[soanvig]

@zcorpan this is extremely limiting, plus probably much harder to implement right. Input was always single line. The moment you add multiple to some input a lot of things currently working with that input (CSS/JS) can break in my opinion. Plus input multiple basically replaces textarea, which is something that isn't wanted probably. Also how the validation should be done on multiline text is rather abiguous.

[RobinWitt]

@zcorpan Why is a pattern useful in an input element? Why shouldnt it be useful for the same reasons in a textarea element?

[zcorpan]

I'm not saying it's not useful. The party proposing a change bears the burden of presenting convincing arguments for the change, and I'm trying to guide how you can do so. If there's concrete examples where this feature would be useful it's possible to assess cost/benefit and how well different proposals address the use cases.

As for <input type=url multiple>, this wasn't meant as "we shouldn't have pattern on textarea" but rather proposing another possible solution to the problem space. Again see https://whatwg.org/faq#adding-new-features , please focus on steps 1 and 2 for now.

[RobinWitt]

Use case:
As a developer, I would like to be able to use the pattern option in textarea elements the same way as they are used for input elements, so I can validate them with the same logic and therefore write more consistent and clean code.

Example:
A Contact Form that has multiple inputs and one textarea, that is supposed to be forwarded via Email. I only want the user to be able to enter plain text into the textarea, no special characters (exceptions and rules could be added via the pattern).

[lionel-rowe]

I think most web developers' mental model of textarea is "text input + newlines + text wrap". Refactoring an input to a textarea is a common operation when requirements change such that you now need newlines and/or text wrap where you didn't before, and the expectation is that attributes like pattern will continue to function.

Can you link to any live sites that are working around the lack of this feature with JS?

I have a live site using a JS workaround for this (for a newline-delimited use case similar to the one I outlined), but it's a platform used internally at my company, not a public-facing site.

There's also this StackOverflow question from 10 years ago with various answers containing JS workarounds. Presumably some others of those are in live use.

[zcorpan]

Usages of data-pattern on textarea found by GitHub code search:
https://github.com/search?type=code&auto_enroll=true&q=%2F%3Ctextarea%5Cs%2B%28%5B%5E%3E%5Cs%5D%2B%5Cs%2B%29*data-pattern%3D%28%22%5B%5E%22%5D%2B%22%7C%27%5B%5E%27%5D%2B%27%29%2F

We can go through some of these (currently 92 files) to learn how it's used.

For example, should the regexp match per line or on the whole value? Which regexp flags?

[lionel-rowe]

Might also be instructive to check for bare pattern attribute on textarea, which has 1.2k results:

https://github.com/search?type=code&auto_enroll=true&q=%2F%3Ctextarea%5B%5E%3E%5D%2B+pattern%3D%2F

Most of those look to be regexes used analogously with input[pattern], so they're either using custom polyfills or they're not providing the validation the authors assumed.

[zcorpan]

@lionel-rowe thanks, good point! There's also the possibility that some are using the attribute in a bogus way and actually expect no validation. In such cases, and possibly in the polyfill cases, starting to support the attribute is a risk to break web compat.

[RobinWitt]

As I am not a native english speaker, just to be clear I understood what you are saying:
Your argument is that people are already using pattern in a textarea with or without knowing that it doesn't work and that this might be an argument for you to not implement it?
Wouldn't that work for the other way around?

[zcorpan]

Yes. If browsers add support for it and that causes web sites to stop working, then it's not implementable. This is something that has happened several times in the past (e.g. <input action>, Array.prototype.flatten).

It might be fine, but it needs some analysis to understand the impact.

[RobinWitt]

Thanks for sharing, helped me a lot to understand.

[sandstrom]

We have textareas where the server-side will look for common spam patterns, such as URLs, and drop those messages. Spammers won't care about pattern (or any client-side validation for that matter), but we want to show a warning to real users.

The pattern attribute on textarea had been great here, because we could let them know that URLs are not allowed.

Right now we've built our own polyfill that pulls the regex from the attribute, runs it in client-side (custom) JS to show a warning. So it works for us, but native support had been better.

[mindaugasvcs]

Can you give concrete examples of where this would be useful?

Preventing submitting whitespace only strings.