Maybe instead we should have a new feature <input trim>.

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.

(In reply to comment #2)
> (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.

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.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

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)

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?

(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.

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.

(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.

(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.

(In reply to comment #9)
> (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?

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.

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.

How about non-breaking spaces? The fixed-width spaces? Bidi formatting characters? Control characters?

There's lots of characters in Unicode that are invisible.

(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.

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.
>>

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.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

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.

(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.

[Reopening to just make sure the editor will see my comment.]

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.

(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;
});

A trim="" attribute wouldn't be a bad idea, indeed. Would it be acceptable?

(In reply to comment #21)
> A trim="" attribute wouldn't be a bad idea, indeed. Would it be acceptable?

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.

(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.

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>

Ok, we can do that, sure.

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:

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>?

(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.

(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 >

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.

(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?

    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.

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.

(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.

(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).

(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.

(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).

I think having the attribute only affect validation would be quite confusing for authors. I don't think it's a good idea.

(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.

Yes, trimming should clearly happen before validation.

This bug was cloned to create bug 17972 as part of operation convergence.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the Editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the Tracker Issue; or you may create a Tracker Issue
yourself, if you are able to do so. For more details, see this document:

   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: No spec change.
Rationale: Let's consider this for HTML.next.

Mass move to "HTML WG"

Mass move to "HTML WG"

HTML5.1 Bugzilla Bug Triage: Interesting idea! Looks like it has some good momentum. Closing this bug in anticipation of seeing this brought into the WICG.

This bug constitutes a request for a new feature of HTML. Our current guidelines, rather than track such requests as bugs or issues, is to create a proposal for the desired behavior, or at least a sketch of what is wanted (much of which is probably contained in this bug), and start the discussion/proposal in the WICG (https://www.w3.org/community/wicg/). As your idea gains interest and momentum, it may be brought back into HTML through the Intent to Migrate process (https://wicg.github.io/admin/intent-to-migrate.html).