Closed Bug 582248 Opened 9 years ago Closed 9 years ago
@list should ensure that the options displayed satisfy validation constraints
No description provided.
So, basically, we should add NSIMETHOD isValid(const nsAString& aValue, PRBool* result) const; to ns[I]ConstraintValidation and do the necessary changes to ns[I]ConstraintValidation implementors.
Yes. The only thing that we need to watch out for is that this should be available for our JS components, but we don't expose this to arbitrary JS. jst suggested adding a function in DOMWindowUtils that would call isValid for us.
So, specifications ask us to filter invalid values showed by the list attribute and our current implementation do not do that. Jonas thinks we should not do that because authors will be limited in the way they can use the list attribute like showing just part of a value. For example, different domain names for email. A domain name isn't a valid email value. IMO, we should do that because I don't think the list should be used to provide a part of a value and selecting an invalid value might be confusing for the user (form being un-submittable because of that). In addition, some websites might have generated values for which they don't know the validity. However, we might want to not filter the values if the form element has the novalidate attribute set. But that could be weird because of the un-consistency. Anyway, I think this should block betaN or final because it would be easy to fix (or to not fix if that's the decision) and it would prevent us to ship a buggy feature (even if the bug isn't major).
David, would you like to work on it if a change is needed?
blocking2.0: ? → betaN+
David, I'm taking this bug given that you told me you don't have so much time these days.
Assignee: dzbarsky → mounir.lamouri
For what it's worth, I don't think we should do this at all. I started a thread in whatwg: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-September/028680.html
I do not agree with points 1 and 3 but I definitely agree that point 2 can be problem and it sounds useless to waste cycles to check something that will be correct most of the time. Anyway, let's wait and see if some people on the list have strong opinions/arguments.
(In reply to comment #7) > For what it's worth, I don't think we should do this at all. I started a thread > in whatwg: > > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-September/028680.html Given that we got only one answer, what should we do? Jonas, did you open a bug in the w3c bug tracker? Do you want me to do that?
Jonas, did you open a W3C bug by any chance? (FWIW, I don't think we should block on that)
Not blocking on this per previous comments.
blocking2.0: betaN+ → -
Given the performance implication, I'm marking this WONTFIX.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
FTR, the specifications changed and this is no longer mentioned (WHATWG HTML r5725).
You need to log in before you can comment on or make changes to this bug.