-
Notifications
You must be signed in to change notification settings - Fork 6.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(input): add support for more input attributes #447
feat(input): add support for more input attributes #447
Conversation
@@ -12,11 +12,20 @@ | |||
[attr.aria-disabled]="ariaDisabled" | |||
[attr.aria-required]="ariaRequired" | |||
[attr.aria-invalid]="ariaInvalid" | |||
[id]="id" | |||
[attr.autocomplete]="autoComplete" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All of the bindings you're adding in this PR are actual properties on HTMLInputElement
, so none of them need attr.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Though note that when using the property tabIndex
is camelCase.
Looks good side from a few minor comments. |
@jelbourn if we use the property notation (eg. [autocomplete]="autoComplete) then the property is always present on the resulting input element. In some cases it's possible to set a default (for example 'off' for autocomplete), but this may not be the required behavior - for example with autocomplete if the property is not set it defaults to the parent form's value, where if we set it explicitly by default to false it will not. It's not clear for other properties (like min and max) what a reasonable default would be. So I think using the attribute notation and only setting the input properties when they have been set on the md-input will give a result closer to normal expectation than using property notation and defaults. It also results in cleaner generated markup - for example not setting step="any" on input[type="text"] elements where it doesn't make sense. This is the behavior that's captured by the tests. Point taken on the parentheses for fixture - that's a quick fix. |
@matthewdenobrega good point, I hadn't seen Angular tacking on the superfluous attributes yet. I also looked at Looks good other than needing a rebase now. |
302b516
to
ba75362
Compare
@jelbourn I've removed the parentheses from the tests and rebased. |
LGTM |
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
@jelbourn I've cleaned up #343 so that it is off an up-to-date master and only one commit.