Using email
and/or password
fields under form
instead of account
when only one is present
#263
Milestone
email
and/or password
fields under form
instead of account
when only one is present
#263
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 likedomain
, 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 theinput
for the specific data type isrequired
, then checking if it's underaccount
) becoming the edge case. Having this all be one field feels like it's pretty much yet another holdover from the days ofaccepts
fields beforeform
, and one that should be outmoded with a clearer embrace ofform
(and #169 to solve for the complexity).The text was updated successfully, but these errors were encountered: