Re: Fwd: comment on DOM 3 Events LC #2 on WebApps WG's request

On 06/16/2011 12:37 PM, Daniel Glazman wrote:
> Le 16/06/11 12:17, Mounir Lamouri a écrit :
>
>> Generally speaking, I think it's too soon to add these kind of events:
>> HTML5 Forms implementations are young and I still haven't see one
>> website using it.
>
> Really a bad argument. Our specs are supposed to pave the future, not
> stabilize what's already here.

I believe pave the future implies to answer to real world use cases and 
my point was just that it's hard to get authors feedback if what is 
currently specified isn't used enough.

>> In addition, I do not think it would be a good idea to have an event
>> being sent when an element becomes valid or invalid: I do not see any
>> good use case (wrt UX) that wouldn't work with the input or change
>> events. What use cases do you have in mind?
>
> A form willing to cancel the transaction after three failed attempts to
> enter something valid ?

I assume that would require submitting the form. There are already ways 
to listen to invalid form submissions with the current HTML specifications.

> A form willing to emit a XHR if a field goes
> off-range or invalid ? There are _tons_ of use case.

Emit an XHR each time a specific form field goes invalid would be a very 
bad idea.
Let say I have an email field. With the empty string, it's valid. If I 
type 'u' it becomes invalid (and the event is sent). When I'm at 
"user@d" the field goes back to valid. And when I'm at "user@domain." 
it's back to invalid. Doing anything while the user is typing would be a 
bad idea IMO and you should emit the XHR on the change event.
Assuming you do not agree, you are able to do exactly what you described 
with the input event. It would be interesting to have a use case of 
these events that wouldn't work (or would be a pain) with the current API..

>> Furthermore, for in-range and out-of-range, I do not believe a good
>> implementation should allow the user to enter an out of range value so
>> such an event might be useless. Even if, I don't see how invalid/valid
>> events wouldn't fulfill the hypothetical use cases of those two.
>
> A "good" implementation ?!?!? Wow. Suppose you have a form with an
> email field. That field's value is populated BY SCRIPT just because
> you have a password helper. Oh, your bad, the data in your passwd
> helper is wrong, you mistyped your email, forgot a period. Dang, the
> form field is invalid.

I was speaking of in-range and out-of-range. IIRC, only 'number', 
'range' and date/time related input types can suffer from being out of 
range. IMO, with a good implementation. the only way to be out of range 
would be to have a script setting the value lower than min or greater 
than max. I don't think creating an event for that case is worthwhile.
And you didn't answer: what would be the value of in-range/out-of-range 
events compared to invalid/valid events (assuming they exist)?

--
Mounir

Received on Sunday, 19 June 2011 00:40:29 UTC