I'm not sure I get the 'increasing the size of the API' argument, can someone expand on it?

To pick a some examples for comparison: Is it worth increasing the size of the API to have valueAsNumber or valueAsDate when both can be easily worked around by the developer if required?  Is it worth adding an output element when we could just have a span and use innerHTML?

Why is this case less worthy than either of those two examples?

I like that an onforminput attribute can be added to the output element.  Even if that isn't really best practice it's simple for beginners to grasp, and it keeps all the logic for each output element in one place (and makes the output element much easier to explain).

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: Since you can't register capturing handlers declaratively, and since form controls can be all over the place in the DOM now, I think 'forminput' and 'formchange' are still very helpful and have clear use cases. As as straightforward demonstration of this, try to rewrite the examples in the spec that use these features to do them without onforminput/onformchange and see whether it's still as simple.

Created attachment 945 [details]
testcase without forminput or formchange

I found 3 examples in the spec and all those can be trivially
handled without these additional events.

Created attachment 946 [details]
testcase

Oops, I left some unrelated alert() in the previous file.
(I was just testing form element's scoping there..)

I'm reopening the bug because, like Olli, I do think forminput and formchange are not needed.

One problem with forminput/formchange -like broadcasting events is that
what should happen when one of the targets is moved to another form
or even another document when some other target for the events is
handling the event. Well, perhaps nothing special shouldn't happen,
but it would be rather strange to get forminput when the element is in a
form which has never been used yet.

In fact, that sort of breaks the algorithm's step 3
"For each element in controls, in tree order, fire a simple event named event
name at the element."
Depending on how you read that, tree order should be checked either just
once before firing any events, or before each event.

> all those can be trivially handled without these additional events

What does your definition of 'trivially handled' encompass?  Here's the amount of JavaScript required in the spec examples purely in terms of character counts (not including spaces):

calculator: 67 characters
password validity: 37 characters
car price: 15 characters

Plus, slightly more meta, understanding of event bubbling required: false.

With your examples:

calculator: 200 characters
password validity: 185 characters
car price: 116 characters

Understanding event bubbling required: true.

I don't agree that you can so easily characterize a minimum of 300% more code and the requirement to understand event bubbling as trivial.

> I do think forminput and formchange are not needed

As I previously asked, why is this not needed, but valueAsNumber is?

(In reply to comment #7) 
You count things strangely. For example in the original car example there is
over 350 characters javascript.


> Understanding event bubbling required: true.
?
I just happened to use addEventListener on document element using
bubble phase. That is not the point.

 
> As I previously asked, why is this not needed, but valueAsNumber is?
This bug is not about valueAsNumber.
I'm personally not at all sure why that is needed.
parseFloat(value) and valueAsNumber are not that different.

Created attachment 947 [details]
testcase 2

With this file, there should be no overhead...

I think we should keep these events and the dispatch APIs. They're exist for convenience, and they are convenient. They're hardly an implementation burden. (Event handler attributes in general are also for convenience but are redundant with addEventListener.)

But what is the use case for the events and the related methods?

I mean use case which can't be trivially done with the existing events.

Use case is updating something when one out of many form controls are changed, using just one declarative event listener. Use case for dispatching the event is causing that event listener to run after some script has changed stuff, maybe initially when loading the page.

Those are not really a use cases, but descriptions how one could
use the events and methods ;)
Also, why couldn't scripts use the existing events for the first case?
And for the latter one there could be just a javascript function to call.

(In reply to comment #14)
> Those are not really a use cases, but descriptions how one could
> use the events and methods ;)

Consider a shopping cart where the customer can select the quantity of each item and the page updates the total amount on the fly. The author generates the shopping cart with PHP but doesn't know enough about javascript and DOM Events to be confident about how to walk the tree or use capturing event listeners (or even that they exist), so instead outputs the calculation script in the onforminput="" attribute with PHP since he already has implemented the logic to output the actual shopping cart itself with PHP. The end result might be something like:

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/804

> Also, why couldn't scripts use the existing events for the first case?

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 for the latter one there could be just a javascript function to call.

If you have several event handler content attributes you would need to call all of them. It's more convenient to dispatch an event.

(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


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


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

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

So, there is still one situation mentioned by Hixie in comment 2 that hasn't been discussed: when form controls are "all over the place". I guess that means:
<form id='f'></form>
<input form='f' name='a'>
<input form='f' name='b'>
<output form='f' onforminput="value=parseFloat(a.value)+parseFloat(b.value);">

In that case we can't indeed use the capture or bubbling phases of the input and change events but I think there is no reason to care too much about this case given that I guess the real use cases to have form controls not descendants of their form owners is when they are very far away in the tree and I would guess that should not happen when you want to have an interaction between form controls.

At worst, it's always possible to do it but it would be more painful:
<form id='f'></form>
<input form='f' name='a' oninput="updateOutput();">
<input form='f' name='b' oninput="updateOutput();">
<output form='f' name='o'>
<script>
  function updateOutput(aForm) {
    aForm.o.value = parseFloat(aForm.a.value) + parseFloat(aForm.b.value);
  }
</script>

(In reply to comment #18)
 
> In that case we can't indeed use the capture or bubbling phases of the input
> and change events 
?

Just add event listener using addEventListener or oninput / onchange to 
document or root element or somewhere and there just check
if event.target.form is the form you're interested in.

(In reply to comment #19)
> (In reply to comment #18)
> 
> > In that case we can't indeed use the capture or bubbling phases of the input
> > and change events 
> ?
> 
> Just add event listener using addEventListener or oninput / onchange to 
> document or root element or somewhere and there just check
> if event.target.form is the form you're interested in.

I would personally prefer oninput on the form controls but both solutions work.
I didn't want to say that there is no solution. I just wanted to make sure all points from comment 2 have been addressed ;)

Hmm, the bubbling nature of these events combined with the change to put the event handlers on every element does make the case for this feature rather weaker. (They were added before we had changed the latter.)

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: see diff given below
Rationale: Concurred with reporter's comments.

Checked in as WHATWG revision r5928.
Check-in comment: Drop forminput and formchange events, and their associated machinery, since you can now put oninput and onchange everywhere which makes them far less compelling.
http://html5.org/tools/web-apps-tracker?from=5927&to=5928

mass-moved component to LC1