582248 - @list should ensure that the options displayed satisfy validation constraints

Status: RESOLVED WONTFIX

(Core :: Layout: Form Controls, defect)

Comment 1

[Mounir Lamouri (:mounir)]

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.

Comment 2

[David Zbarsky (:dzbarsky)]

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.

Comment 4

[Mounir Lamouri (:mounir)]

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

Comment 5

[Mounir Lamouri (:mounir)]

David, would you like to work on it if a change is needed?

Comment 6

[Mounir Lamouri (:mounir)]

David, I'm taking this bug given that you told me you don't have so much time these days.

Comment 7

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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

Comment 8

[Mounir Lamouri (:mounir)]

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.

Comment 9

[Mounir Lamouri (:mounir)]

(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?

Comment 10

[Mounir Lamouri (:mounir)]

Jonas, did you open a W3C bug by any chance?
(FWIW, I don't think we should block on that)

Comment 11

[Johnny Stenback (:jst)]

Not blocking on this per previous comments.

Comment 12

[Mounir Lamouri (:mounir)]

Given the performance implication, I'm marking this WONTFIX.

Comment 13

[Mounir Lamouri (:mounir)]

FTR, the specifications changed and this is no longer mentioned (WHATWG HTML r5725).