W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > October 2011

[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

From: <bugzilla@jessica.w3.org>
Date: Tue, 11 Oct 2011 04:55:12 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1RDUMy-0002QW-AW@jessica.w3.org>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:02:05 UTC