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

Using email and/or password fields under form instead of account when only one is present #263

Closed
stuartpb opened this issue Feb 21, 2017 · 1 comment
Milestone

Comments

@stuartpb
Copy link
Member

stuartpb commented Feb 21, 2017

Honestly, I'm pretty sure this is the right call to make: account.accepts should never have one item (or maybe only when it's something esoteric like domain, and even then, I'm not sure).

I mean, at that point, it's not really an account input so much as it is whatever the one value type it accepts is, and it'd be better if forms just reflected that (especially as you might have email-or-username-input-specific properties attached, like "does this have type="email" set). Right now, we have the awkward situation of "dedicated inputs are only used when both are presented", and it leads to something that should be the primary check (checking if the input for the specific data type is required, then checking if it's under account) becoming the edge case. Having this all be one field feels like it's pretty much yet another holdover from the days of accepts fields before form, and one that should be outmoded with a clearer embrace of form (and #169 to solve for the complexity).

@stuartpb stuartpb changed the title Using email and/or password fields under form instead of account when only one is present Using email and/or password fields under form instead of account when only one is present Feb 21, 2017
@stuartpb stuartpb added this to the v0.1.0 milestone Feb 21, 2017
@stuartpb
Copy link
Member Author

Yeah, I'm ready to go ahead with this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant