[whatwg] Text areas with pattern attributes?
ian at hixie.ch
Sat Aug 29 18:44:26 PDT 2009
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
> 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 .
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
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg