This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This was was cloned from bug 13769 as part of operation convergence. Originally filed: 2011-08-12 23:00:00 +0000 Original reporter: Marat Tanalin | tanalin.com <mtanalin@yandex.ru> ================================================================================ #0 Marat Tanalin | tanalin.com 2011-08-12 23:00:36 +0000 -------------------------------------------------------------------------------- Currently, whitespace value is considered valid during browser-side form validation according to "required" boolean attribute of a form element. This is contrary to practices of server-side form validation where leading and trailing whitespace is usually removed (trimmed) before validation since whitespace is usually not useful data of any kind. So, it makes sense to make browser-side validation consistent with good server-side validation practices: whitespace-only values should be full equivalent to zero-length value and should be considered empty too. Thanks. ================================================================================ #1 Anne 2011-08-13 09:41:52 +0000 -------------------------------------------------------------------------------- Maybe instead we should have a new feature <input trim>. ================================================================================ #2 Mounir Lamouri 2011-08-15 14:59:52 +0000 -------------------------------------------------------------------------------- I wouldn't like trimming required fields, it would break some use cases like <input type='password' required>: the user wouldn't be allowed to type spaces-only password. Not that it would be a good idea, but the specs shouldn't make this impossible. In addition, if we do the trimming the same way we do it for <input type='email'> and <input type='url'> (ie, in the value sanitization algorithm), that would modify passwords beginning or ending with spaces. (In reply to comment #1) > Maybe instead we should have a new feature <input trim>. Sounds a good idea if the attribute doesn't apply to type=password and interact directly with the value sanitization algorithm. ================================================================================ #3 Aryeh Gregor 2011-08-15 18:56:51 +0000 -------------------------------------------------------------------------------- I don't see why it shouldn't apply to type=password. vBulletin, for instance, trims password fields. It's useful to do so if the user copy-pastes a password, like from a password reset e-mail, and accidentally gets a leading or trailing space. It may or may not be ideal, but it shouldn't be prohibited. ================================================================================ #4 Ian 'Hixie' Hickson 2011-08-17 05:01:08 +0000 -------------------------------------------------------------------------------- Status: Did Not Understand Request Change Description: no spec change Rationale: Is this just for type=text? The idea being to require that people type in more than just spaces? If so, isn't the pattern attribute sufficient? (pattern=".*[^ ].*" for example) ================================================================================ #5 Jonas Sicking 2011-08-22 20:55:19 +0000 -------------------------------------------------------------------------------- Sure, you could use a pattern for this. But that's not a great solution if everywhere where the author uses @required they'd also have to have @pattern. The question to me is how common is it to have a required field where white-space only is a ok value? It seems to me that this would be a very rare edge case. If it is in fact a very rare edge case, then wouldn't it be better so solve it using the .setCustomValidity method? ================================================================================ #6 Marat Tanalin | tanalin.com 2011-08-31 10:24:46 +0000 -------------------------------------------------------------------------------- (In reply to comment #4) > Is this just for type=text? It's for any text fields to be manually edited by user (textarea, input type="text"/"url", etc.). > The idea being to require that people > type in more than just spaces? The idea is that this is definition of what _all_ required fields are. > If so, isn't the pattern attribute sufficient? > (pattern=".*[^ ].*" for example) Sufficient for what exactly? It's formally (maybe) "sufficient", but is semantically wrong. Same as <div class="paragraph"> formally could be used everywhere instead of structural paragraph element (<p>), but this would be semantically wrong at all. "required" attribute is part of semantics, while "pattern" attribute is just an acceptable solution for rare custom cases. Leading/trailing whitespace in text-field values is meaningless in most of cases (99%, if not all), so leading and trailing whitespace should be trimmed _by default_ and this should not need to use something more than just "required" attribute. Just try to imagine terrible scenario when ALL required text fields in all forms always have not only "required" attribute, but, additionally, pattern: <input type="name" required pattern=".*[^ ].*" /> <input type="email" required pattern=".*[^ ].*" /> <textarea name="text" required pattern=".*[^ ].*"></textarea> This would be a maintenance nightmare and really a "culmination" of HTML-spec sense, purpose, and quality. Good HTML spec should not force web-developers to use such harmful, nonsemantic, and unusable approaches. Instead, we should be able to just use "required" attribute only: <input type="name" required /> <input type="email" required /> <textarea name="text" required></textarea> See also comment 5 by Jonas Sicking. Thanks. ================================================================================ #7 Anne 2011-08-31 11:55:38 +0000 -------------------------------------------------------------------------------- While I am not sure what the use case is for preserving leading and trailing whitespace, trimming whitespace would be a backwards incompatible change. Only trimming whitespace when the required="" attribute is set would be inconsistent. If we do anything I would still favor something like what I suggested in comment 1. ================================================================================ #8 Marat Tanalin | tanalin.com 2011-08-31 13:29:22 +0000 -------------------------------------------------------------------------------- (In reply to comment #7) What exact negative impact (any really serious) you think such backwards-incompatibility can have in this case? As web-developer with 10-years experience, I think there is no actual compatibility problem here: client-side validation is purely _assisting_ functionality, it's just about usability for user, it does _not_ ensure that data sent to server are actually valid at all. All data should be validated on server-side _anyway_, so it's completely wrong to rely on client-side validation only. On the contrary, trimming whitespace by default for required fields will be just positive _evolution_ that will make client-side validation _consistent_ with server-side one: leading/trailing whitespace is _always_ trimmed on server-side in real-world web-applications. ================================================================================ #9 Ian 'Hixie' Hickson 2011-09-03 19:55:04 +0000 -------------------------------------------------------------------------------- (In reply to comment #5) > The question to me is how common is it to have a required field where > white-space only is a ok value? It seems to me that this would be a very rare > edge case. How common is it to have a required text field where a single period is an ok value? Or a single dash? Or the string "no answer provided"? Or a non-breaking space? I'm rather skeptical about making required="" go down this road. I much prefer orthogonal features that are simple to explain and simple to understand. IMHO if the author wants a particular value, then that's what the pattern="" attribute is for. ================================================================================ #10 Marat Tanalin | tanalin.com 2011-09-03 23:14:53 +0000 -------------------------------------------------------------------------------- Whitespace has one fundamental distinctive: whitespace is INVISIBLE exactly like empty string (and unlike nonwhitespace characters that can be manually typed-in from keyboard -- like period or dash you mentioned). That's why whitespace is always trimmed on server-side before server-side validation on any well-developed website. Client-side validation should be just consistent with server-side one. ================================================================================ #11 Jonas Sicking 2011-09-04 06:58:26 +0000 -------------------------------------------------------------------------------- Indeed, I think the important distinction between whitespace and a single dash or the string "no answer provided" is that whitespace is invisible to the user. It's very easy to start inputting something and then remove everything but a single whitespace. Hence it seems like a common erroneous value to leave which wouldn't be caught until a roundtrip to the server was made. ================================================================================ #12 Ian 'Hixie' Hickson 2011-09-27 19:49:40 +0000 -------------------------------------------------------------------------------- How about non-breaking spaces? The fixed-width spaces? Bidi formatting characters? Control characters? There's lots of characters in Unicode that are invisible. ================================================================================ #13 Marat Tanalin | tanalin.com 2011-09-29 21:28:52 +0000 -------------------------------------------------------------------------------- (In reply to comment #12) If you want, you are free to trim all that Unicode whitespace stuff. But, in real world, it's enough to trim ASCII-whitespace only -- since this is the only what can be typed-in with keyboard. Thus, it's enough to do same action as PHP's (widely-used server-side language) standard function named trim(): http://php.net/manual/en/function.trim.php By the way, standard JavaScript's String object has standard method trim() too: https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/String/Trim We could define URL-trimming same way as the JS-method is defined. ================================================================================ #14 Marat Tanalin | tanalin.com 2011-09-30 07:01:50 +0000 -------------------------------------------------------------------------------- There is a typo in last sentence of my comment 13, it should be read as follows instead: << We could define form-field value trimming same way as the JS-method is defined. ================================================================================ #15 Ian 'Hixie' Hickson 2011-09-30 19:50:57 +0000 -------------------------------------------------------------------------------- You can insert Unicode bidi formatting characters pretty easily in Windows builds with bidi enabled (it's in the context menu for the text field). Should we trim those too? (That would break many Arabic use cases, amongst others.) Special-casing " " here seems really weird to me. It makes the API more magical, which makes it less understandable. If your server is willing to accept what looks like invisible input such as control characters, or barely-visible input like ".", then it's not at all clear to me why a single space would be any different. This is what pattern="" is _made_ for. ================================================================================ #16 Ian 'Hixie' Hickson 2011-09-30 20:08:28 +0000 -------------------------------------------------------------------------------- Status: Rejected Change Description: no spec change Rationale: Making required="" special-case one of the many invisible characters in Unicode would lead authors to simply not think about this case at all, which isn't really an option IMHO. Only removing invisible characters still doesn't really solve the problem, which is that for freeform fields there's all kinds of ways of not answering. Why would we make users use "." instead of " " if they want to work around the form claiming that a freeform field is required? In fact, making a freeform field required doesn't make that much sense to start with. It makes sense for cases that have particular data structure (e.g. types other than text, or when there's a pattern), but why would you mark a freeform field as "required" and then disallow " " but not "."? In the case where you really want to disallow just spaces, but are ok with letting the user work around this in one of the many other ways one can do so, the pattern="" attribute already provides a simple way to do so. If people use that pattern a lot, that would be good evidence that I'm wrong here, but in the absence of evidence to that effect, I don't think the arguments presented are compelling enough to justify making the language somewhat magical here. ================================================================================ #17 Marat Tanalin | tanalin.com 2011-09-30 20:26:05 +0000 -------------------------------------------------------------------------------- (In reply to comment #15) While you just _assume_, we as web-developers exactly _know_: if a field is required, there is no and there should no any difference between literally zero-length string and whitespace-only string. There is already enough argumentation here to accept this. Adding pattern to _all_ required fields is obviously not a rational option. For exact characters to trim, see PHP's trim() function. > If your server is willing to accept what looks like invisible input such as > control characters, or barely-visible input like ".", then it's not at all > clear to me why a single space would be any different. Unclear phrase for me. ===== Again and last time: browser-side validation is NOT about security AT ALL. It's about user's MISTAKES and improving USABILITY of forms by preventing redundant "submit -> server-side validation error" iteration. If user _want_ to work around validation, he will do this anyway. But that case has nothing to do with validation as usability measure to prevent user's MISTAKES. If the bug will not be fixed, then web-developers will likely just use 'required' attribute (without garbage 'pattern' attribute, of course), thus still forcing user to make mistakes by accidental typing-in invisible characters and sending this to server and returning same form with server-side validation errors. ================================================================================ #18 Marat Tanalin | tanalin.com 2011-09-30 20:26:45 +0000 -------------------------------------------------------------------------------- [Reopening to just make sure the editor will see my comment.] ================================================================================ #19 Ian 'Hixie' Hickson 2011-09-30 21:42:50 +0000 -------------------------------------------------------------------------------- I find it hard to believe that it is common for users to _accidentally_ enter space characters in a required free-form text field that they actually intend to fill in. ================================================================================ #20 Marat Tanalin | tanalin.com 2011-10-01 21:17:25 +0000 -------------------------------------------------------------------------------- (In reply to comment #19) See comment 11. By the way, it maybe could be more flexible (and therefore more feasible for the editor to accept) to add new 'trim' boolean attribute -- as Anne has proposed in comment 1. This could have benefits for both sides: 1. default definition of 'required' state keeps simple as it is currently; 2. when needed (in fact, always), web-developers could automatically add trim attribute to all required fields by using trivial JavaScript like this: [].slice.call(document.querySelectorAll('[required]'), 0).forEach(function() { this.trim = true; }); ================================================================================ #21 Ian 'Hixie' Hickson 2011-10-02 05:24:18 +0000 -------------------------------------------------------------------------------- A trim="" attribute wouldn't be a bad idea, indeed. Would it be acceptable? ================================================================================ #22 Marat Tanalin | tanalin.com 2011-10-02 15:11:51 +0000 -------------------------------------------------------------------------------- Definitely better than nothing. Formal description of expected 'trim' functionality just in case: if 'trim' attribute will be added to the spec, it should have same result as if 'required' attribute itself has default behavior defined as "zero-length string is equivalent to whitespace-only string". In other words, adding 'trim' attribute should cause showing same browser-validation message for whitespace-only strings as is showing currently for zero-length strings. ================================================================================ #23 Mounir Lamouri 2011-10-02 16:55:24 +0000 -------------------------------------------------------------------------------- (In reply to comment #21) > A trim="" attribute wouldn't be a bad idea, indeed. Would it be acceptable? A trim attribute as proposed by Anne that would remove the leading a trailing whitespaces during the value sanitization algorithm would be a good idea I think. ================================================================================ #24 Marat Tanalin | tanalin.com 2011-10-02 19:19:12 +0000 -------------------------------------------------------------------------------- By the way, it would be nice to be able to use 'trim' attribute not only on individual fields, but on forms and maybe fieldsets. This probably would be ideal solution -- very usable and elegant. Having 'trim' attribute specified for a form could have same result as if all of the form's fields had individual 'trim' attributes. For example: <form action="#" trim> <input name="lorem" /> <input name="ipsum" /> <textarea name="dolor"></textarea> </form> would be equivalent to: <form action="#"> <input name="lorem" trim /> <input name="ipsum" trim /> <textarea name="dolor" trim></textarea> </form> ================================================================================ #25 Ian 'Hixie' Hickson 2011-10-03 18:54:52 +0000 -------------------------------------------------------------------------------- Ok, we can do that, sure. ================================================================================ #26 Marat Tanalin | tanalin.com 2011-10-04 22:29:21 +0000 -------------------------------------------------------------------------------- Unfortunately, the editor has overlooked textarea and fieldset elements when updating summary. It probably and hopefully is purely accidental, so I've edited the summary to reflect these unaccounted elements. Besides, just in case, I've added testcase URL that trims a string on server side using PHP's standard trim() function and thus illustrates expected trimming effect. To be clear (just in case too), whitespace characters set includes at least following ones: ================================================================================ #27 Ian 'Hixie' Hickson 2011-10-06 00:29:01 +0000 -------------------------------------------------------------------------------- Trimming from the start of <textarea> seems dangerous, as it might change the meaning of the value (consider, e.g., a use pasting in some python code). Could you elaborate on the use case for trim="" on <fieldset>? ================================================================================ #28 Mounir Lamouri 2011-10-06 08:44:04 +0000 -------------------------------------------------------------------------------- I believe like for <form>: applying to all descendants. ================================================================================ #29 Marat Tanalin | tanalin.com 2011-10-06 15:52:18 +0000 -------------------------------------------------------------------------------- (In reply to comment #27) > Trimming from the start of <textarea> seems dangerous, as it might change the > meaning of the value (consider, e.g., a use pasting in some python code). Since using trim attribute is completely optional (unlike to embedding trimming to 'required' attribute functionality) and therefore, if used, is purely intentional, there are no problems at all. If author adds 'trim' attribute, then he exactly knows that trimming for particular field is needed and is OK anyway. If trimming for the field is not needed, author will just not add 'trim' attribute. (In reply to comment #28) > (In reply to comment #27) > > Could you elaborate on the use case for trim="" on <fieldset>? > > I believe like for <form>: applying to all descendants. Exactly. For example, required fields (which values are needed to be trimmed always in real world) could be groupped into a separate fieldset. For example: <fieldset trim> <input name="lorem" /> <input name="ipsum" /> <textarea name="dolor"></textarea> </fieldset > would be equivalent to: <fieldset> <input name="lorem" trim /> <input name="ipsum" trim /> <textarea name="dolor" trim></textarea> </fieldset > ================================================================================ #30 Ian 'Hixie' Hickson 2011-10-11 22:55:53 +0000 -------------------------------------------------------------------------------- Regarding textarea, I fear people would use it inappropriately, so it would be a problem. For example, one could imagine this very textarea I'm using right now being marked trim="", since most of the time that makes sense. But if I had started this comment with some indented code, it would break the first line's indentation. I could see an argument for trimming just leading and trailing newlines, rather than newlines and spaces; what do you think? For the fieldset case, do you have an example of a Web page that groups controls in this way? I don't want to add it to fieldset unless it's clear that authors really are using fieldset in this way, otherwise it's just bloat. ================================================================================ #31 Marat Tanalin | tanalin.com 2011-10-11 23:56:38 +0000 -------------------------------------------------------------------------------- (In reply to comment #30) > Regarding textarea, I fear people would use it inappropriately, so it would be > a problem. For example, one could imagine this very textarea I'm using right > now being marked trim="", since most of the time that makes sense. But if I had > started this comment with some indented code, it would break the first line's > indentation. There is no much sense to start a _message_ from indentation in general and from code in particular. Code in message is usually prepended with a summary what code is related for. If any of leading/trailing whitespace characters in particular field is important (for example, if a textarea is intended _exactly_ to type _code_ and only _code_ into it), then author will just not use trim attribute for such textarea at all. > I could see an argument for trimming just leading and trailing newlines, rather > than newlines and spaces; what do you think? I think it would be inconsistent with server-side trimming as well as JavaScript String.trim() function and therefore confusing. There is quite clear and well-known definition of what is string trimming, and there is no need for inventing a fantom difficulties and unexpected limitations here. > For the fieldset case, do you have an example of a Web page that groups > controls in this way? I don't want to add it to fieldset unless it's clear that > authors really are using fieldset in this way, otherwise it's just bloat. It's well-known usability principle for forms: to group related (required ones in particular) fields together. For example, imagine big registration form that starts from a few required fields (like username, password, and e-mail) followed by optional ones (like living city or ICQ number). I could of course create an live example of such form for you, but I doubt it makes much sense. After all, both forms and fieldsets are containers for fields, and if we could use trim attribute for forms, why couldn't we use this on fieldset to get more flexibility? ================================================================================ #32 Ian 'Hixie' Hickson 2011-10-12 00:36:14 +0000 -------------------------------------------------------------------------------- There is no much sense to start a _message_ from indentation in general and from code in particular. The very message I'm writing here starts with indentation. If we had trim="", it would prevent me from writing what I am writing here. I'm not sure this is a good idea. I agree that it makes sense in one-line text fields. But I don't think it makes sense in textareas. Do you have examples of pages that trim the contents of textareas before submission today? I would be interested in studying such pages to see how they handle this issue. It's well-known usability principle for forms: to group related (required ones in particular) fields together. For example, imagine big registration form that starts from a few required fields (like username, password, and e- mail) followed by optional ones (like living city or ICQ number). If it's as well-known as you say, surely it should be easy to demonstrate that someone somewhere has done this. Are there real Web pages (not demo pages created for this bug!) that show that authors group input fields that they trim into fieldsets, such that the trim="" attribute on <fieldset> would help them? The reason I ask is because I suspect that actually people _don't_ do this, in which case providing a feature to make it easier really doesn't serve much purpose other than to bloat the language. ================================================================================ #33 Mounir Lamouri 2011-10-12 00:54:40 +0000 -------------------------------------------------------------------------------- I agree that trim on textarea would very likely goes wrong.(In reply to comment #30) > Regarding textarea, I fear people would use it inappropriately, so it would be > a problem. For example, one could imagine this very textarea I'm using right > now being marked trim="", since most of the time that makes sense. But if I had > started this comment with some indented code, it would break the first line's > indentation. > > I could see an argument for trimming just leading and trailing newlines, rather > than newlines and spaces; what do you think? I don't think it would be a good idea to have <input trim> doing X and <textarea trim> doing Y. I would prefer to not have trim on textarea given that it's not really clear what that should do. > For the fieldset case, do you have an example of a Web page that groups > controls in this way? I don't want to add it to fieldset unless it's clear that > authors really are using fieldset in this way, otherwise it's just bloat. I agree with this. I don't see why fieldset should have a trim attribute that would add the trim functionality to all descendants. We only do that for disabled (and the use case here is pretty obvious). If we do it for trim, why not for other attributes like required? Adding attributes applying to all fieldset descendants isn't common. Though, I think this also apply to form element. Why do we want to add trim to the form element? Do we have obvious use cases? How many elements in a form would usually require the trim attribute? Only text field seem to have a real need of it. I think we should probably begin by adding trim to input element (and make it apply only to some types) and forget the other elements for the moment. Nothing forbids us to add trim to other elements later if the need is more obvious. ================================================================================ #34 Marat Tanalin | tanalin.com 2011-10-12 22:55:08 +0000 -------------------------------------------------------------------------------- (In reply to comment #32) > Do you have examples of pages that trim the contents of textareas before > submission today? I would be interested in studying such pages to see how they > handle this issue. http://foxconn.ru/company/feedback/ > Are there real Web pages (not demo pages > created for this bug!) that show that authors group input fields that they trim > into fieldsets, such that the trim="" attribute on <fieldset> would help them? It seems we've somewhat beared off the initial bug-point. Grouping is not about trimmed elements at all. _Required_ fields are grouped. The whole point of 'trim' attribute is to use in conjunction with 'required' attribute. We don't need to alter data actually sent to server (we do trimming on server-side). We need to just prevent sending required fields that contain whitespace-only as their values. Embedding trimming feature into 'required' attribute functionality itself is not enough flexible for you, OK. Then 'trim' attribute gives us that enough flexibility. Again: we do NOT need to alter values sent to server at all. All the bug is about is to treat whitespace-only values identically to literally empty values. For descriptive reasons, I've created demo page that emulates expected functionality with JavaScript: http://tanalin.com/_experimentz/bugs/w3/html/trim/required/ The demo page contains form with two fieldsets. First of the fieldsets has 'required' attribute specified and is used to group required fields together, while 'trim' boolean attribute (also specified for the fieldset) says browser to treat whitespace-only values of descendant fields invalid exactly as literally empty values are. P.S. By the way, should I file a new bug dedicated to adding 'required' attribute to 'fieldset' and 'form' elements (one more clever feature to generalize forms, fieldsets, and form fields), or we could discuss that in current topic? Thanks. ================================================================================ #35 Marat Tanalin | tanalin.com 2011-10-12 23:05:57 +0000 -------------------------------------------------------------------------------- (In reply to comment #33) > Why do we want to add trim to > the form element? Do we have obvious use cases? How many elements in a form > would usually require the trim attribute? Only text field seem to have a real > need of it. Any feedback form. Feedback forms are often consist of text fields only. And also often, all fields in feedback forms are required. 'trim' attribute is purely subordinate feature as to 'required' attribute which is primary one (see comment 34). ================================================================================ #36 Ian 'Hixie' Hickson 2011-10-24 18:27:51 +0000 -------------------------------------------------------------------------------- (In reply to comment #34) > > http://foxconn.ru/company/feedback/ This page is a classic example of why this is silly. I was able to submit the form with "-" as the textarea contents, which is just as useless as submitting it with " ". It's not like I would enter blank spaces accidentally but would not enter dashes accidentally. Anyway, I agree with Mounir. We should start by adding this to <input type=text>, with the behaviour just being that the value's start and end spaces are trimmed when editing (whether this is exposed to the user is a UA issue). Then we can see how commonly this is used and how common it is for people to do it across an entire form or fieldset and how common it is for people to need it for textarea, and go from there for WF4. ================================================================================ #37 Marat Tanalin | tanalin.com 2011-10-24 21:50:34 +0000 -------------------------------------------------------------------------------- (In reply to comment #36) > (In reply to comment #34) > > > > http://foxconn.ru/company/feedback/ > > This page is a classic example of why this is silly. I was able to submit the > form with "-" as the textarea contents, which is just as useless as submitting > it with " ". It's not like I would enter blank spaces accidentally but would > not enter dashes accidentally. You are repeating yourself. I'm not going to do the same though. See comment 10 and comment 11. > Anyway, I agree with Mounir. We should start by adding this to <input > type=text>, with the behaviour just being that the value's start and end spaces > are trimmed when editing (whether this is exposed to the user is a UA issue). > Then we can see how commonly this is used and how common it is for people to do > it across an entire form or fieldset and how common it is for people to need it > for textarea, and go from there for WF4. Mounir's intention was probably just like "finally do at least something" as for trimming. As for me personally, now after your proposal to drop <time> element (bug 13240) I'm not going to be surprised at any of your decisions as for HTML5 at all. Just in case, please take into account (again) that 'trim' attribute should affect value examined by built-in client-side validation only. Trimming actual value before sending it to server is generally pointless. The only point to trim value is to inform browser to treat whitespace-only values as literally empty strings when validating according to 'required' attribute (see initial description of this bug). ================================================================================ #38 Ian 'Hixie' Hickson 2011-10-26 23:29:14 +0000 -------------------------------------------------------------------------------- I think having the attribute only affect validation would be quite confusing for authors. I don't think it's a good idea. ================================================================================ #39 Marat Tanalin | tanalin.com 2011-10-27 16:12:07 +0000 -------------------------------------------------------------------------------- (In reply to comment #38) Trimming just _makes sense_ mainly as for validation. Anyway, it should be at least clearly described in the HTML5 spec that trimming should be applied _before_ validating according to 'required' attribute. Otherwise we could face with wrong implementations where validation says "OK" (field is not empty though contains whitespace-only characters) and _then_ trimming is applied, and [now] empty string is sent to server. This absurd situation should be ruled out by clear definition of trimming in the spec. Thanks. ================================================================================ #40 Ian 'Hixie' Hickson 2011-10-28 19:53:16 +0000 -------------------------------------------------------------------------------- Yes, trimming should clearly happen before validation. ================================================================================
What does "operation convergence" mean?
Marking this LATER to separate it from more urgent bugs; will reopen and reconsider in January.
*** Bug 18774 has been marked as a duplicate of this bug. ***
Bug 15291 suggests this is something that some people do want, but not many.
So I just reread all the comments above and I'm not really sure I understand what _exactly_ it is we want here. Say you have an <input> that you've set trim="" on. - Does the user see any difference when editing? - Does the user see any difference when submitting? - What does the .value attribute expose? - What gets submitted? - Does this do anything when required='' isn't set? Given the data in bug 15291, do we still want to actually support this?
(In reply to Ian 'Hixie' Hickson from comment #5) `pattern` attribute has almost nothing to do with this. Original intent was just to ignore leading and trailing whitespace (extremely trivial thing actually) when validating form-element's value according to `required` attribute (e.g. by validating copy of `element.value` processed by `String.trim()` JS-method [1]). Nothing else should have been affected (e.g. element's value should have been sent to server as is, without trimming). When that (clear and widely used in server-side programming) idea has been rejected, adding the `trim` attibute (proposed by Anne) has been considered as an acceptable (though less usable) alternative (web developers then would be forced to use JavaScript to add `trim` attribute automatically to all `INPUT`/`TEXTAREA` elements that have `required` attribute, via `DOMContentLoaded` event handler; suboptimal, but at least better than nothing). If you have spent your time to reread all the comments, you probably should have time to think over what does that mean. Maybe it makes sense to reconsider ignoring leading/trailing whitespace when validating form-element's value according to `required` attribute (best and extremely clear option for me and most likely for any practicing web developer). [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/Trim
So that would be: - Does the user see any difference when editing? No - Does the user see any difference when submitting? No - What does the .value attribute expose? User's unedited input - What gets submitted? User's unedited input - Does this do anything when required='' isn't set? No ...right? (pattern="" is relevant because, as shown in bug 15291's data, people are working around the lack of this using pattern='' to say "there has to be something other than whitespace here".)
(In reply to Ian 'Hixie' Hickson from comment #7) > So that would be: > > - Does the user see any difference when editing? No > - Does the user see any difference when submitting? No > - What does the .value attribute expose? User's unedited input > - What gets submitted? User's unedited input > - Does this do anything when required='' isn't set? No > > ...right? Looks like. > (pattern="" is relevant because, as shown in bug 15291's data, people are > working around the lack of this using pattern='' to say "there has to be > something other than whitespace here".) Using workarounds like `pattern` attribute and/or JavaScript for trimming whitespace during validation is an inevitable consequence of lack of a dedicated feature for this purpose. `pattern` attribute is a least-evil solution for cases that are _not_ covered by _dedicated_ features. Trimming whitespace during form-element's value validation is general enough to have a dedicated feature like `trim` attribute (suboptimal, but better than `pattern`) or to be a part of an existing `required` attribute (best option that is most semantic and clean). People using `pattern` attribute to trim whitespace for validation purposes will almost certainly end up with using it always in conjunction with `required` attribute: <input name="lorem" required pattern="[nonwhitespace_pattern]" /> <input name="ipsum" required pattern="[nonwhitespace_pattern]" /> thus making the code to be a terrible littered soup; or, even worse, without `required` attribute at all: <input name="lorem" pattern="[nonwhitespace_pattern]" /> <input name="ipsum" pattern="[nonwhitespace_pattern]" /> thus making the code less semantic. `required` and (more or less) `trim` attributes are parts of semantics, while `pattern` attribute is not. Best option is to incorporate whitespace-trimming functionality into existing semantic `required` attribute: <input name="lorem" required /> <input name="ipsum" required /> Such code is most clean, natural, semantic and easy to use.
> Using workarounds like `pattern` attribute and/or JavaScript for trimming > whitespace during validation is an inevitable consequence of lack of a > dedicated feature for this purpose. Yes. The point is we can look at how common such workarounds are as a proxy for determining how common the problem is. The data from the aforementioned bug suggests that minlength="" is needed a lot, because a lot of patterns worked around the lack of minlength=""; however, relatively few pages seem to work around the lack of trim="". > Best option is to incorporate whitespace-trimming functionality into > existing semantic `required` attribute: > > <input name="lorem" required /> > <input name="ipsum" required /> > > Such code is most clean, natural, semantic and easy to use. This would mean you couldn't have a required form field where spaces were a valid thing to enter, which seems really weird and unintuitive. Another question I hadn't considered before now: how should this interact with minlength="", maxlength="", and pattern=""?
(In reply to Ian 'Hixie' Hickson from comment #9) > > Best option is to incorporate whitespace-trimming functionality into > > existing semantic `required` attribute: > > > > <input name="lorem" required /> > > <input name="ipsum" required /> > > > > Such code is most clean, natural, semantic and easy to use. > > This would mean you couldn't have a required form field where spaces were a > valid thing to enter, which seems really weird and unintuitive. Could you provide a real-world usecase when whitespace-only value is expected and making sense for a required field? I didn't encounter such cases for last 11 years. Moreover, I always trim whitespace during both server-side and client-side validation. > Another question I hadn't considered before now: how should this interact > with minlength="", maxlength="", and pattern=""? `pattern` attribute should not be affected more (or work differently) than without having the trimming feature. `pattern` should operate with `element.value` that is not affected by trimming at all as we've already concluded before. Same apparently should apply to `minlength` and `maxlength` -- they both should operate with unaffected `element.value`.
(In reply to Marat Tanalin | tanalin.com from comment #10) > Could you provide a real-world usecase when whitespace-only value is > expected and making sense for a required field? > > I didn't encounter such cases for last 11 years. Moreover, I always trim > whitespace during both server-side and client-side validation. I concur that I have never seen such a case, cannot think of one, and am skeptical that one exists in the real world. Normally you want to ignore leading and trailing whitespace in text fields, because it can easily sneak in by accident due to copy-pasting, and trailing whitespace is invisible. The user can't visually tell the difference between a field that's empty and that contains only whitespace, so making form submission depend on the difference is very poor UI. From that perspective, "required" should perhaps require that the field contain some *visible* character (excluding all Unicode whitespace, control characters, etc.). I don't see a use-case for a form field that is required but allows an all-whitespace value. In the unlikely event someone can find one, pattern=".+" should do what they want. "required" would best be kept for the normal usecase where a non-whitespace value is required.
A trivial example of a control that should be required but where a single space is a perfectly valid input (and one that I often put in, actually) would be the top control on this page: http://software.hixie.ch/utilities/cgi/unicode-decoder/character-identifier If trim="" is ignored by minlength="", what should happen if the user enters two spaces into the following control?: <input trim="" minlength="10"> (If they enter no spaces, the control will be submitted fine, since it's not required="", but if it _was_ required="", but didn't have a length, it would _not_ submit, because trim="" means that required="" needs something that's not spaces.) (In reply to Marat Tanalin | tanalin.com from comment #10) > > I didn't encounter such cases for last 11 years. Moreover, I always trim > whitespace during both server-side and client-side validation. I've never encountered a need to trim before testing if the user had entered a value on a Web form in 15 years, FWIW. :-) I don't think anecdotes are a good basis on which to design the spec, though.
(In reply to Ian 'Hixie' Hickson from comment #12) > If trim="" is ignored by minlength="", what should happen if the user enters > two spaces into the following control?: > > <input trim="" minlength="10"> > > (If they enter no spaces, the control will be submitted fine, since it's not > required="", but if it _was_ required="", but didn't have a length, it would > _not_ submit, because trim="" means that required="" needs something that's > not spaces.) `trim` attribute is meant to make sense _solely_ in conjunction with `required` attribute and must be ignored if `required` attribute is missing. Whitespace trimming is a subfeature of the `required` feature only. So your example is equivalent to: <input minlength="10" /> And this case has nothing to do with this bug. This bug is about `required` attribute (and `trim` as its possible [though undesired] supplement). How any other attributes (that I don't [and shouldn't] care actually at all) should function is subject to be resolved in other bugs.
(In reply to Ian 'Hixie' Hickson from comment #12) > A trivial example of a control that should be required but where a single > space is a perfectly valid input (and one that I often put in, actually) > would be the top control on this page: > > > http://software.hixie.ch/utilities/cgi/unicode-decoder/character-identifier Granted, but that's a very uncommon case and would be perfectly well served by pattern=".+". Do you have any examples that occur in the sort of typical, 80% web apps we're designing for? > If trim="" is ignored by minlength="", what should happen if the user enters > two spaces into the following control?: > > <input trim="" minlength="10"> Good point. For consistency, probably a new concept would have to be introduced of "values that should be treated as empty for inputs", and you'd want to change a variety of things to fit. A trim="" attribute that only changes the meaning of required="" and doesn't do anything else sounds like a bad idea -- in fact, I'd expect such an attribute to trim even before submission. If the feature is really supposed to only affect required="", it should be called required="trim" or something. I would change the meaning of required="" itself. > I've never encountered a need to trim before testing if the user had entered > a value on a Web form in 15 years, FWIW. :-) I don't think anecdotes are a > good basis on which to design the spec, though. How much experience do you have writing widely-deployed web apps? The two large projects whose code I'm familiar with, MediaWiki and vBulletin, both strip whitespace from inputs at least in some cases (vBulletin does routinely last I checked). These are exactly the sort of projects we should be looking at to determine what sort of feature set to optimize for, because they have the largest user-base and will be the best refined to meet user needs. If authoring experience counts as anecdote, I don't know what standards you're judging use-cases by. An example of a common field where you'd always want to strip whitespace before checking that the field was provided is a username field. No software I've ever heard of allows a whitespace-only username.
To answer my own question: an example of a required field that you might not want to trim whitespace from is a password field. If you allow leading and trailing whitespace in a password, but require passwords to be at least one character long, you want required="" to accept a whitespace-only value. This still might allow for an opt-in feature like required="trim" or something, which is what was originally proposed. The question is whether it's useful enough to bother adding when you can normally do the same with pattern="" -- that I'm not sure about at all, and I'm currently inclined to say no.
So if the user enter " ": <input> - submits <input required=""> - submits <input required="" trim=""> - doesn't submit (missing) <input minlength="10"> - doesn't submit (too short) <input required="" minlength="10"> - doesn't submit (too short) <input required="" trim="" minlength="10"> - doesn't submit (missing) That's kind of weird, but ok. (In reply to Marat Tanalin | tanalin.com from comment #13) > > This bug is about `required` attribute This bug is about a use case, not a solution. > (and `trim` as its possible [though undesired] supplement). The trimming feature itself is "undesired", IMHO. Let's put aside our opinions here and just focus on how we can solve the use cases in a way that doesn't hurt other people's use cases.
> #12 Ian 'Hixie' Hickson 2011-09-27 19:49:40 +0000 > -------------------------------------------------------------------------------- > How about non-breaking spaces? The fixed-width spaces? Bidi formatting > characters? Control characters? > There's lots of characters in Unicode that are invisible. HTML spec clearly defines a set of space characters: https://html.spec.whatwg.org/multipage/infrastructure.html#space-character http://www.w3.org/TR/html/infrastructure.html#space-character
If this is still desired, please file a new issue over at https://github.com/whatwg/html/issues/new.