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

[Bug 11129] Remove forminput, formchange and related dispatch methods

From: <bugzilla@jessica.w3.org>
Date: Thu, 27 Jan 2011 10:09:50 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1PiOnW-0002sj-Ch@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11129

--- Comment #17 from Simon Pieters <simonp@opera.com> 2011-01-27 10:09:49 UTC ---
(In reply to comment #16)
> (In reply to comment #15)
> > http://software.hixie.ch/utilities/js/live-dom-viewer/saved/804
> So that could be written close the way the example 1 or 3 in 
> http://www.w3.org/Bugs/Public/attachment.cgi?id=947

Ah. I assumed that change and input didn't bubble. That makes my case weaker
indeed.

> > You need a capturing event listener for that, which is not available as markup
> > and many authors who know enough to use event handler attributes don't know
> > that capturing event listeners exist or how they work.
> And why exactly do you need capturing event listeners?

Since change and input bubble, I don't. I do need to name="" my <output>s and
put the logic further away from the <output>s, but that's not a big deal.


> > If you have several event handler content attributes you would need to call all
> > of them. It's more convenient to dispatch an event.
> So why would it be more convenient to split the code to several
> forminput/change event handlers than just have one function?

Each <output> updates its own value when something changes. Just a different
coding style.

-- 
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 Thursday, 27 January 2011 10:09:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 27 January 2011 10:09:54 GMT