Skip to content
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

Merged
merged 2 commits into from
May 18, 2016

Conversation

matthewdenobrega
Copy link
Contributor

@jelbourn I've cleaned up #343 so that it is off an up-to-date master and only one commit.

@googlebot googlebot added the cla: yes PR author has agreed to Google's Contributor License Agreement label May 16, 2016
@@ -12,11 +12,20 @@
[attr.aria-disabled]="ariaDisabled"
[attr.aria-required]="ariaRequired"
[attr.aria-invalid]="ariaInvalid"
[id]="id"
[attr.autocomplete]="autoComplete"
Copy link
Member

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.

Copy link
Member

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.

@jelbourn
Copy link
Member

Looks good side from a few minor comments.

@matthewdenobrega
Copy link
Contributor Author

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

@jelbourn
Copy link
Member

@matthewdenobrega good point, I hadn't seen Angular tacking on the superfluous attributes yet. I also looked at tabIndex with Misko today and it seems that it's going to need special handling in core due to its weirdness.

Looks good other than needing a rebase now.

@matthewdenobrega
Copy link
Contributor Author

@jelbourn I've removed the parentheses from the tests and rebased.

@jelbourn
Copy link
Member

LGTM

@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 5, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
cla: yes PR author has agreed to Google's Contributor License Agreement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants