[whatwg] Text areas with pattern attributes?

[Ian Hickson]

On Wed, 19 Aug 2009, Alex Vincent wrote:
>
> I'm drifting into writing code for the pattern attribute on text fields 
> again, and I wondered:  if text inputs can have pattern attribute for 
> regular expression matching, why not text area elements?

Lack of compelling use cases.


On Wed, 19 Aug 2009, Aryeh Gregor wrote:
> 
> You could impose a minimum character length for posts -- that's common 
> on forums.  Or ban certain words or phrases.  As always, presumably 
> you'd have server-side enforcement too.

We could have minlength="", but it doesn't seem compelling enough.

Banning words isn't something I think we should be encouraging.


On Mon, 24 Aug 2009, Chris Taylor wrote:
> 
> It's been mentioned before about limiting the length of text permissible 
> in a <textarea> element, specifically for forums. Part of my JavaScript 
> library-ish thing makes this slightly easier for authors to use: 
> http://performerjs.org/docs/limiter. I have no data about which sites 
> the Performer script is used on, unfortunately.

This is possible with maxlength="".


> The other types of patterns I can imagine being used include text where 
> newlines may be required at certain points for example CSV data, or 
> lists that will be parsed into separate items server-side. Also a 
> pattern to respond to certain words, for example qualifications (e.g. 
> "Doctorate" or "Degree"). Also for spam checking, although as we all 
> know too well it is almost impossible to completely stop the input of 
> unwanted words. IRT also has a couple of script examples involving 
> textareas, however these may be more complex than the spec pattern 
> attribute can handle [1].

I don't think these really are compelling enough.


On Tue, 25 Aug 2009, Anne van Kesteren wrote:
> 
> Also, maxlength cannot be enforced as client-side validation requirement 
> due to compatibility issues.

I thought we had worked around that with the dirty value flag?



On Wed, 19 Aug 2009, Jonas Sicking wrote:
> >
> > What's the use-case for it? Textareas are almost always for such large 
> > amounts of input that they are almost always free-form text. Why allow 
> > the pattern attribute?
> 
> A similar argument was made against putting the placeholder attribute on 
> <textarea>, until someone found a page where it was used.

Indeed. The same argument is used for all features in HTML5.


> I think in general it makes very little sense to say that <textarea>s 
> are different from <input type=text>. Technically the only difference is 
> that one is multiline and the other is not. So it seems like anything 
> that makes sense in <input type=text> makes sense in <textarea>.
> 
> So for the pattern attribute, a use case would be on a site that accepts 
> US addresses (for example a store that only ships within the US), the 
> site could use a textarea together with a pattern that matches US 
> addresses.

Show me the correct regular expression for that, then argue with a 
straight face that we should actually have that feature, and I'll add it. :-)


On Wed, 19 Aug 2009, Mike Shaver wrote:
> 
> It's also pretty common to enter multiple email addresses or tracking 
> numbers or URLs one-per-line for batch operations on sites, and they 
> would benefit from having client-side validation of such patterns.

This is handled by <input type=email multiple>.


On Mon, 24 Aug 2009, Alex Vincent wrote:
> 
> Well, if the spec authors decide NOT to support the pattern attribute on 
> text areas, I would ask the spec authors to insert a note (normative or 
> not) explaining the rationale.

If we start adding notes for everything that's not in the spec, the spec 
will balloon in size. I don't think that's a workable strategy.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'