- From: Ian Hickson <ian@hixie.ch>
- Date: Sun, 30 Aug 2009 01:44:26 +0000 (UTC)
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. `._.-(,_..'--(,_..'`-.;.'
Received on Saturday, 29 August 2009 18:44:26 UTC