[Bug 12230] From this algorithm it does not seem to follow that dispatching a synthetic non-canceled submit event at a form causes it to be submitted. Yet that is what browsers implement. So that forms have a default handler for submit events should probably be split

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12230

--- Comment #21 from Jonas Sicking <jonas@sicking.cc> 2011-10-11 04:55:10 UTC ---
Actually, you're arguing that there should be three types of events:

1. Events which are strictly notifications
2. Events which are notifications that something is about to happen, but where
   the "something" can be cancelled. 
3. Events which carry a inherent default action which always happens when the
   event is submitted, but where the default action can be cancelled.

Examples of group 1 is things like "load" and "visibilitychange"

Examples of group 2 is things like "error" in indexedDB (cancels transaction
unless cancelled), "downloading"/"checking" in AppCache (displays UI in the
browser).

Examples of group 3 would be "click" and "submit".

I argue that we should abandon group 3 and let those events belong to group 2
instead. That way we have fewer types of events. Additionally all events would
simply be some form of notification.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Tuesday, 11 October 2011 04:55:13 UTC