md-input-container: ng-touched added on page load

[epelc]

I think this commit has broken the styles for md-input-container. It's adding the invalid styles when the page is loaded instead of after the user first touches the input. Also I believe ng-touched is not supposed to be added on page load.

[epelc]

I should mention this is for inputs with required and possible the min/max length attributes.

[ThomasBurleson]

@epelc - here is the issue. If the input field is invalid during page load/initialization, the previous solution does not indicate such. As soon as you touch it and defocus it shows the error style. This is a horrible UX: if the value is invalid show the style immediately. Hence the change(s).

[epelc]

@ThomasBurleson What about for required fields? It makes your form look terrible if half your inputs are red when they load especially for a sign in page. Also the user has a general idea that most things are required why do we have to scream it to them when they show up? Wouldn't it be better to guide them as they fill out the form instead?

As a side note this is also how most forms already work so it breaks what the user has already learned. Ie google's sign up page only warns you about an invalid input after you have touched it or input something invalid.
https://accounts.google.com/SignUp

[grabbou]

@ThomasBurleson I believe it should show the error as soon as you touch it. For now - even simple login form is completely red as "required" & "email" are obviously wrong on first page load.

Also - on initial page load, my ng-messages are showing ng-message="required" by default.

and without ng-if="form.input.$dirty" (should not be needed)

With above approach, doing more complex form of any kind to handle API endpoints is just not going to work.

[AllenSH12]

FWIW here's what the Material spec says on the topic:
http://www.google.com/design/spec/patterns/errors.html#errors-user-input-errors

[grabbou]

+1 @AllenSH12

[ThomasBurleson]

@AllenSH12 - Thank you for the link. I did not realize that Material Design is explicit. Very nice... now I will queue this issues as a definite bug. Thx again.

[AllenSH12]

@ThomasBurleson no problem!

[AllenSH12]

In the meantime I tweaked the Error demo to demo the behavior more explicitly, PR here: #1491

[ThomasBurleson]

@grabbou - can you provide a CodePen or Plunkr that I can use to verify changes ?

[grabbou]

Can do, will update this tomorrow.

[ThomasBurleson]

@AllenSH12 , @epelc - can you check with latest in master to confirm that this issue has been resolved ? Thank you.

[epelc]

@ThomasBurleson It seems be to fixed on the latest master. But I also think it's odd how it immediately becomes invalid when you touch it(before you type anything). I think a delay or some other sort of logic to wait until after you type something would be better. But these rules are a bit hard to get right.

I also noticed on google stripe and github they don't even show validation errors on their signin page.

[ThomasBurleson]

@epelc - I followed the Material Design spec which states:

Error text should not appear before user interaction with the field.

For me this means that a click or focus on the element is a "user interaction". Thus the immediate indication that the error condition exists.

[epelc]

@ThomasBurleson I think you did it right. It seems correct on every other form I have besides the login page. Perhaps because so many sites don't validate your input on login pages I've been tricked into expecting this.

[AllenSH12]

@ThomasBurleson looks good thank you again

[AllenSH12]

(sorry accidentally submitted last comment before ready, continuing...)

@ThomasBurleson is there anything I can do to have my PRs merged instead of included indirectly in the future?

[ThomasBurleson]

@AllenSH12 - I asked you in your PR if you had signed the CLA. You did not reply. So I copied your changes. I will only merge valid changes from contributors if a the required CLA has been signed.

[AllenSH12]

@ThomasBurleson that makes sense, thank you for clarifying.

[fuhlig]

The error stil exists (as shown below on the demo site). Seems like .md-input-invalid is not toggled correctly on <md-input-container>

[ThomasBurleson]

@fuhlig - re-opening to fix.

[grabbou]

Yep, can confirm that @fuhlig issue appears in mine project as well. Weird, as material demo seems to handle that properly.

[mbellezi]

I think this problem is related: If you use the browser memorized values for common fields (Name, city, etc.), the fields are filled with the values but the md-input-container does not update properly. Using a e-mail validated field, for example, when autocompleted, you have to type several times for the update in the container takes place. You can test here:

http://codepen.io/mbellezi/pen/ByxdJB

[ThomasBurleson]

Fixed, Closed with SHA 747eb9c