Re: [whatwg] Text areas with pattern attributes?
On Tue, Sep 29, 2009 at 11:43 PM, Ian Hickson i...@hixie.ch wrote: So add 'multiple' on all of those and you'll have a good reason you'd want them all to be able to wrap over multiple lines. I.e. ability to enter multiple bank numbers, multiple social security numbers or multiple usernames. I could see an argument for input type=text pattern=... multiple. That's probably best left for a future version though. But I don't think that's the same as multiline input. If you could specify that a pattern could match multiple times you would also need to specify the delimiter. Support for multiple should also be very easy by just modifying your pattern without support for a multiple attribute. All of these seem like a bad idea to keep separate for multiline inputs vs. single line inputs. Except for the default value which for historic reasons make sense to use separate mechanisms, and cols/size which are both mostly rendering differences. It's not clear how list= would work with textarea, and I'm not aware of any UA that does textarea autocomplete. The closest example of this that I can think of is Facebook's autocomplete for messages, but even adding autocomplete to a textarea wouldn't make it possible to implement what they have. I could see pattern being supported for textarea, but in the same way as a text input. I think it's okay to require JavaScript and use the custom validation system for more complex validation, especially for this version.
Re: [whatwg] Text areas with pattern attributes?
On Mon, 31 Aug 2009, Jonas Sicking wrote: On Mon, Aug 31, 2009 at 12:04 AM, Ian Hicksoni...@hixie.ch wrote: On Sun, 30 Aug 2009, Jonas Sicking wrote: Ok, addresses might not be the best example. I would imagine that most use cases for pattern for a single line, carries over if you want to have that single line wrap and be displayed as multiple lines. So if you can provide the list of use cases that was used to add pattern on single-line input and I'd be very surprised if not most of them carries over to multi-line. The main use cases that were considered as far as I recall were credit card numbers and other bank numbers (we originally considered type=cc but that turned out to be more locale-specific than expected), social security numbers and other formatted serial numbers, and username fields that exclude certain characters. So add 'multiple' on all of those and you'll have a good reason you'd want them all to be able to wrap over multiple lines. I.e. ability to enter multiple bank numbers, multiple social security numbers or multiple usernames. I could see an argument for input type=text pattern=... multiple. That's probably best left for a future version though. But I don't think that's the same as multiline input. The difference between input type=text and textarea is mostly a rendering one. One scrolls the text when it can't fit, the other wraps. Do you really think that creates enough of a difference that the feature set should be different? The feature sets are different in many other ways. This is hardly an exception. For example, textarea has no list= support, cols= works differently than size=, the default value is set differently, textarea doesn't support autocomplete, etc. All of these seem like a bad idea to keep separate for multiline inputs vs. single line inputs. Except for the default value which for historic reasons make sense to use separate mechanisms, and cols/size which are both mostly rendering differences. It's not clear how list= would work with textarea, and I'm not aware of any UA that does textarea autocomplete. I don't necessarily think all this is how I would design this if we were starting from scratch, but we're not, and I don't think we should be making them consistent at this point without good use cases. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Text areas with pattern attributes?
On Tue, Aug 25, 2009 at 4:24 PM, Aryeh Gregorsimetrical+...@gmail.com wrote:
For that matter, it might be nice if some patterns just refused to let
you enter anything that doesn't meet the pattern -- but not all,
clearly. E.g., [ -~]* to restrict to ASCII would really like to
just not let you type other characters, but that's not workable for
.{10,} to set a minimum length. Possibly this is too much
complication for the time being, however.
Oh, patterns, I love these. Let's play, let's play!
https://account.nokia.com/acct/register?serviceId=Ovicomlid=acctregrtnavlang=es-419
This page (and its relatives) is great for patterns.
Si no halas ustedes Español podria visitar al: http://translate.google.com/t
Here's our first input:
1. Su nombre de usuario y contraseña
Nombre de usuario (obligatorio)
Ingrese 3 a 32 caracteres. El nombre de usuario sólo puede contener
números, '.', '-' y '_'.
[]
Google's translation:
1. Your username and password
Username (required)
Revenue [should be Enter] 3 to 32 characters. The username can
contain only numbers, '.', '-' And '_'.
Ah, but you don't speak Spanish? ok, let's try the English language
version of that page:
https://account.nokia.com/acct/register?serviceId=Ovicomlid=acctregrtnavlang=en-US
1. Your user name and password
User name (mandatory)
Please enter 3 to 32 characters. User name can only contain letters,
numbers, '.', '-' and '_'.
And no, Google did not make a mistake in its translation from Spanish
(just check the other Spanish).
Anyway, let's try entering a value into this text field, please allow
me to suggest .123, it's a perfectly reasonable thing according to
both sets of instructions.
The results from English are:
Your user name can only contain numbers and letters, not symbols.
Patterns are wonderful things, but people rarely get them right. I
don't think Ovi is uniquely talented here. I suppose that in theory if
Ovi were to have had a pattern input object and relied on the user
agent to give the user a set of valid characters, they might not have
provided the wonderful strings they did (which are well... both
breathtaking and spectacular), however, I doubt that.
OTOH, as someone who is working on an embedded system (Maemo 5), I can
say that we've asked our Input Method team for the ability to specify
an arbitrary set of allowed characters, and they've refused :). We've
asked them nicely, and repeatedly, and they've insisted it isn't
something they'll support. Among other reasons, they claim it's
confusing :)
(The IM team does not work with Ovi.)
Please note that textareas today support both onchange and
oninput. I've recently switched from using onchange to oninput for a
tiny niche web app of mine. The ovi example would greatly benefit from
this same change.
Adding a pattern thing would not really help. Especially given how
screwy patterns can be.
If you want to do something with input, the right thing to do is to
disable the submit button and explain to the user why you didn't like
their input. Well, at least, if you can manage to come up with a
proper explanation. If web authors really think they're incapable of
providing correct explanations, they're in trouble, because as noted,
not everyone will have whatever feature you're asking for here today,
which means you'll need to do the work anyway (and please do get it
right, at least in English, if not in Spanish).
Re: [whatwg] Text areas with pattern attributes?
On Wed, Aug 26, 2009 at 10:18 AM, Max Romantschukm...@romantschuk.fi wrote: I think it's important not to forget that a great deal of web applications are internal applications not exposed to the Internet. In an environment like that performance issues with evaluating regexps against a large body of text are less of an issue, since the workstations used are under the control of the organization the application is internal to. This is mostly nonsense. I work for a rather large company in your country. We have standards for desktop/laptop PCs (namely, you can only use one that you get by ordering from the company's selection of models), but we also issue each person a cell phone (we make them ourselves, we're rather proud of this, it's a Sisu thing -- i suppose). Our cell phones have software enabling VPN access, so any of my colleagues can take his/her n95, e71, n97, or n900 and connect it to our intranet. Sadly, performance issues on Mobile devices are a big concern to my group and most of the rest of the company, except for the people who develop the web apps we use. If you want a better example, I'll note that both Nokia and Oracle use PAC (Proxy Auto Config), which relies heavily on regular expressions. Oracle's were so huge that it exposed a serious bug in Mozilla's JS code. Nokia's are just so convoluted that they cause any browser which uses them to hang periodically on network lookups. Just because a feature is available doesn't mean the people who use it will be aware of how poorly they're using it. For PAC files from both companies, i'd estimate that it affects 95% or more of their employees, this hasn't resulted in either company's IT department changing them. And the problems are serious, having your browser crash trying to visit the pages you have to visit or having it hang for a while whenever you try to go anywhere. Relying on groups to be aware of the ramifications of using regular expressions, especially wrt speed/performance is foolhardy at best.
Re: [whatwg] Text areas with pattern attributes?
On Thu, Sep 3, 2009 at 8:07 PM, timelesstimel...@gmail.com wrote: Si no halas ustedes Español podria visitar al: http://translate.google.com/t How embarrassing, I fixed the typo elsewhere: Si no hablas ustedes Español podria visitar al: http://translate.google.com/t
Re: [whatwg] Text areas with pattern attributes?
On Sun, Aug 30, 2009 at 10:42 PM, Jonas Sickingjo...@sicking.cc wrote: The difference between input type=text and textarea is mostly a rendering one. One scrolls the text when it can't fit, the other wraps. input type=text also can't contain newlines. Of course, another solution would be to allow input type=text to change rendering to be that of a textarea, and teach the world to migrate from textarea to input type=text. That would seem more semantically correct. I actually think it's reasonable to argue that there's a meaningful difference between a field designed to contain a single value, like a username or social security number, and a field designed to contain free-form text. I don't think things like autocomplete (or associated features like datalist) really make any sense for textareas, for example. Some browsers also spell-check textareas by default and not input type=text, and so on. Of course, by this logic, authors should use still textarea or something for one-line free-form text inputs, like the subject field of an e-mail form. But there are styling issues that would have to be overcome for that to work.
Re: [whatwg] Text areas with pattern attributes?
On Sun, 30 Aug 2009 03:44:26 +0200, Ian Hickson i...@hixie.ch wrote: 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? I misremembered. However, there is another compatibility problem with the maxLength DOM attribute. I filed a bug on that. (When the content attribute is missing the DOM attribute should return -1, not 0.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Text areas with pattern attributes?
On Sun, 30 Aug 2009, Jonas Sicking wrote: Ok, addresses might not be the best example. I would imagine that most use cases for pattern for a single line, carries over if you want to have that single line wrap and be displayed as multiple lines. So if you can provide the list of use cases that was used to add pattern on single-line input and I'd be very surprised if not most of them carries over to multi-line. The main use cases that were considered as far as I recall were credit card numbers and other bank numbers (we originally considered type=cc but that turned out to be more locale-specific than expected), social security numbers and other formatted serial numbers, and username fields that exclude certain characters. The difference between input type=text and textarea is mostly a rendering one. One scrolls the text when it can't fit, the other wraps. Do you really think that creates enough of a difference that the feature set should be different? The feature sets are different in many other ways. This is hardly an exception. For example, textarea has no list= support, cols= works differently than size=, the default value is set differently, textarea doesn't support autocomplete, etc. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Text areas with pattern attributes?
On Mon, Aug 31, 2009 at 12:04 AM, Ian Hicksoni...@hixie.ch wrote: On Sun, 30 Aug 2009, Jonas Sicking wrote: Ok, addresses might not be the best example. I would imagine that most use cases for pattern for a single line, carries over if you want to have that single line wrap and be displayed as multiple lines. So if you can provide the list of use cases that was used to add pattern on single-line input and I'd be very surprised if not most of them carries over to multi-line. The main use cases that were considered as far as I recall were credit card numbers and other bank numbers (we originally considered type=cc but that turned out to be more locale-specific than expected), social security numbers and other formatted serial numbers, and username fields that exclude certain characters. So add 'multiple' on all of those and you'll have a good reason you'd want them all to be able to wrap over multiple lines. I.e. ability to enter multiple bank numbers, multiple social security numbers or multiple usernames. The difference between input type=text and textarea is mostly a rendering one. One scrolls the text when it can't fit, the other wraps. Do you really think that creates enough of a difference that the feature set should be different? The feature sets are different in many other ways. This is hardly an exception. For example, textarea has no list= support, cols= works differently than size=, the default value is set differently, textarea doesn't support autocomplete, etc. All of these seem like a bad idea to keep separate for multiline inputs vs. single line inputs. Except for the default value which for historic reasons make sense to use separate mechanisms, and cols/size which are both mostly rendering differences. / Jonas
Re: [whatwg] Text areas with pattern attributes?
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 textareas 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. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Text areas with pattern attributes?
On Sat, Aug 29, 2009 at 9:44 PM, Ian Hicksoni...@hixie.ch wrote: 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. For one of the 3 cases, yes. What for the other 2? Should we specify input type=text multiple, for related but distinct text entries? Mike
Re: [whatwg] Text areas with pattern attributes?
On Sat, 29 Aug 2009, Mike Shaver wrote: On Sat, Aug 29, 2009 at 9:44 PM, Ian Hicksoni...@hixie.ch wrote: 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. For one of the 3 cases, yes. What for the other 2? Should we specify input type=text multiple, for related but distinct text entries? I've not seen a multiple URL input field before, but if that's a problem worth solving, we can in the future make multiple= apply to type=url also. I agree that pattern= might make sense for multiline code entry. However, unless that's much more common than I've so far seen, I don't think it hits our 80% bar. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Text areas with pattern attributes?
Smylers wrote: The point is to have cases specifically _for_ it -- not adding everything for which there isn't a reason against. If textarea pattern=... wouldn't in practice be used by authors then there's no point in adding it. If it would be used then it should be trivial to show some places where it would be used. I think it's important not to forget that a great deal of web applications are internal applications not exposed to the Internet. In an environment like that performance issues with evaluating regexps against a large body of text are less of an issue, since the workstations used are under the control of the organization the application is internal to. Personally I just feel that a unified interface is more valuable than holding author's hands and preventing them from making unwise design choices. If an input field used with the pattern attribute for inputting a single value needs to be changed to a multi-line textarea with the same pattern repeated not having pattern for textareas would mean a great deal of extra work for authors. Granted, my judgement is clouded... I've always felt that the separation of input type=text and textarea seemed unnatural. I guess I'm just personally against widening the gap when the difference from a user's perspective is that one is single-line and the other multi-line. :) .max -- Max Romantschuk m...@romantschuk.fi http://max.romantschuk.fi/
Re: [whatwg] Text areas with pattern attributes?
On Tue, Aug 25, 2009 at 3:05 AM, Anne van Kesterenann...@opera.com wrote:
Also, maxlength cannot be enforced as client-side validation requirement due
to compatibility issues.
Hmm, I hadn't thought of that. You're right, that would provide
somewhat inconsistent behavior. On the other hand, just not letting
you type any more is if anything probably better than an error
message. I don't see why you'd ever *want* the behavior of
pattern=.{0,n} for maxlength=n.
For that matter, it might be nice if some patterns just refused to let
you enter anything that doesn't meet the pattern -- but not all,
clearly. E.g., [ -~]* to restrict to ASCII would really like to
just not let you type other characters, but that's not workable for
.{10,} to set a minimum length. Possibly this is too much
complication for the time being, however.
Re: [whatwg] Text areas with pattern attributes?
On Tue, Aug 25, 2009 at 3:05 AM, Anne van Kesterenann...@opera.com
wrote:
Also, maxlength cannot be enforced as client-side validation
requirement due to compatibility issues.
Hmm, I hadn't thought of that. You're right, that would provide
somewhat inconsistent behavior. On the other hand, just not letting
you type any more is if anything probably better than an error
message. I don't see why you'd ever *want* the behavior of
pattern=.{0,n} for maxlength=n.
With maxlength (as implemented in current browsers) it's not possible
to paste string that is too long and then trim it to desired length,
e.g. if I have Your order reference is AB-456 in my clipboard, I
can't use it in input field that has maxlength=6.
So I wish maxlength behaved more like pattern in all cases :)
--
regards, Kornel
Re: [whatwg] Text areas with pattern attributes?
On Tue, Aug 25, 2009 at 12:05 AM, Anne van Kesteren ann...@opera.comwrote: Also, maxlength cannot be enforced as client-side validation requirement due to compatibility issues. I don't grasp what you're saying here. Are you saying that maxlength or ValidityState.tooLong() cannot be implemented as specced? PK
Re: [whatwg] Text areas with pattern attributes?
On Tue, 25 Aug 2009 18:57:59 +0200, Peter Kasting pkast...@google.com wrote: On Tue, Aug 25, 2009 at 12:05 AM, Anne van Kesteren ann...@opera.comwrote: Also, maxlength cannot be enforced as client-side validation requirement due to compatibility issues. I don't grasp what you're saying here. Are you saying that maxlength or ValidityState.tooLong() cannot be implemented as specced? I was trying to say something else (Web Forms 2.0 was at one point modified to only enforce maxlength if the value was actually changed by the user and I misremembered how that was solved), but it turns out what is specified clashes with a jQuery extension to the textarea element as well :/ Not sure how to address that. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Text areas with pattern attributes?
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. I also believe that it would be beneficial to have an option to regex-validate a text area in cases like this. One might argue that a case like this is served by having an AJAX interface with multiple inputs, but in my experience a lot of real world office work involves the worlds most used database, the spreadsheet. It's not far fetched to imagine copy-pasting a bunch of data from a spreadsheet column into a textarea, in which case it would make sense to be able to have client side validation for a given pattern repeated n times with newlines in between. I really don't see a case for not allowing pattern for a textarea. The implementation side should not be that different from the same attribute on a text input? Except for the client side overhead of parsing a large amount of data against a regex, what would be the drawbacks on having pattern on textareas? .max -- Max Romantschuk m...@romantschuk.fi http://max.romantschuk.fi/
Re: [whatwg] Text areas with pattern attributes?
Aryeh Gregor writes: On Wed, Aug 19, 2009 at 11:32 AM, Geoffrey Sneddongsned...@opera.com 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? You could impose a minimum character length for posts -- that's common on forums. Or ban certain words or phrases. Are there currently sites using JavaScript to perform the above checks pre-submission? If so, would the checks be easier to write using a pattern attribute than they currently are? (If they aren't then it seems unlikely authors would bother with it.) Max Romantschuk writes: 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. I also believe that it would be beneficial to have an option to regex-validate a text area in cases like this. It's not far fetched to imagine copy-pasting a bunch of data from a spreadsheet column into a textarea, in which case it would make sense to be able to have client side validation for a given pattern repeated n times with newlines in between. Are there any such sites already? If there aren't, it seems unlikely that the lack of textarea pattern=... is what's holding them back. I really don't see a case for not allowing pattern for a textarea. The point is to have cases specifically _for_ it -- not adding everything for which there isn't a reason against. If textarea pattern=... wouldn't in practice be used by authors then there's no point in adding it. If it would be used then it should be trivial to show some places where it would be used. Smylers
Re: [whatwg] Text areas with pattern attributes?
Smylers wrote: Are there currently sites using JavaScript to perform the above checks pre-submission? The point is to have cases specifically _for_ it -- not adding everything for which there isn't a reason against. If textarea pattern=... wouldn't in practice be used by authors then there's no point in adding it. If it would be used then it should be trivial to show some places where it would be used. 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. 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]. Chris [1] http://www.irt.org/script/1024.htm http://www.irt.org/script/1047.htm http://www.irt.org/script/690.htm This message has been scanned for malware by SurfControl plc. www.surfcontrol.com
Re: [whatwg] Text areas with pattern attributes?
On Mon, Aug 24, 2009 at 9:08 AM, Chris Taylor chris.tay...@figureout.comwrote: It's been mentioned before about limiting the length of text permissible in a textarea element, specifically for forums. textarea is defined to support maxlength already ( http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element ). I think pattern is significantly less valuable than maxlength, but it wouldn't be too difficult to add support for it. I vote weakly against. PK
Re: [whatwg] Text areas with pattern attributes?
2009/8/24 Peter Kasting pkast...@google.com: I think pattern is significantly less valuable than maxlength, but it wouldn't be too difficult to add support for it. I vote weakly against. More than that I'm a little concerned about potential performance drawbacks: having a pattern to be applied completely on a veeery long textarea could be a problem, such things can't be left to authors' good will. IMO. -- Bye, Michelangelo
Re: [whatwg] Text areas with pattern attributes?
On Mon, Aug 24, 2009 at 6:04 AM, Max Romantschukm...@romantschuk.fi wrote: I really don't see a case for not allowing pattern for a textarea. The implementation side should not be that different from the same attribute on a text input? Except for the client side overhead of parsing a large amount of data against a regex, what would be the drawbacks on having pattern on textareas? 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. Reason: I have this funny feeling I've asked about pattern attributes on text areas before. I think the question will be raised in the future. All of this has happened before, and it will happen again. -- The first step in confirming there is a bug in someone else's work is confirming there are no bugs in your own. -- Alexander J. Vincent, June 30, 2001
Re: [whatwg] Text areas with pattern attributes?
On Mon, Aug 24, 2009 at 11:22 AM, Smylerssmyl...@stripey.com wrote:
Are there currently sites using JavaScript to perform the above checks
pre-submission?
There are many sites that use server-side checks for those purposes.
For instance, almost any site running the popular vBulletin forum
software imposes a minimum length on posts. I don't know if many
sites do client-side checks, but I'd imagine more would if it were
easier.
I should say that I can't see myself personally using pattern on textareas.
If so, would the checks be easier to write using a pattern attribute
than they currently are?
Yes. For instance, checking for a minimum length of 10 characters is
just pattern=.{10,}. Currently you'd have to do . . . I don't even
know offhand. My JavaScript isn't good enough. I'd have to spend
some time with online references to figure it out. Almost every web
developer is very familiar with regex; not every web developer knows
much JS. On the other hand, anyone who can write a JavaScript event
handler offhand can definitely handle pattern=.
I've recently been adding HTML 5 form features to MediaWiki, and found
that I was using features that I'd never have considered figuring out
the right JS for, because it was so simple. For instance, MediaWiki
currently uses JavaScript to autofocus forms on only a couple of
pages. When I saw that the autofocus attribute was available and
worked in a few significant browsers, I started adding it to every
single page where it made sense -- which means most form-based pages.
Also things like type=number that we just relied on server-side
validation for. Just because authors aren't currently going to the
trouble of writing JS doesn't mean they wouldn't use easier methods if
they were available.
On Mon, Aug 24, 2009 at 1:49 PM, Peter Kastingpkast...@google.com wrote:
On Mon, Aug 24, 2009 at 9:08 AM, Chris Taylor chris.tay...@figureout.com
wrote:
It's been mentioned before about limiting the length of text permissible
in a textarea element, specifically for forums.
textarea is defined to support maxlength already
( http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element ).
There's no minlength, though.
Re: [whatwg] Text areas with pattern attributes?
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? 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? -- Geoffrey Sneddon — Opera Software http://gsnedders.com/ http://www.opera.com/
Re: [whatwg] Text areas with pattern attributes?
On Wed, Aug 19, 2009 at 11:32 AM, Geoffrey Sneddongsned...@opera.com 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? 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.
Re: [whatwg] Text areas with pattern attributes?
On Wed, Aug 19, 2009 at 8:32 AM, Geoffrey Sneddongsned...@opera.com wrote: 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? 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. I think in general it makes very little sense to say that textareas 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. / Jonas
Re: [whatwg] Text areas with pattern attributes?
2009/8/19 Jonas Sicking jo...@sicking.cc: 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. That would be a most unusual scenario IMO: I've never encountered such a format. Postal addresses are usually quite structured, I guess nobody would impose a pattern on a single giant address (textarea), instead multiple form elements (input) could be used together to compose a postal address, even to provide a finer grain check on user's data. My two cents. -- Bye, Michelangelo
Re: [whatwg] Text areas with pattern attributes?
On Wed, Aug 19, 2009 at 2:38 PM, Jonas Sickingjo...@sicking.cc wrote: 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. 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. Mike
