[whatwg] This step must be skipped if the form has no onreceived attribute

[Jim Ley]

On Wed, 23 Jun 2004 16:19:26 +0000 (UTC), Ian Hickson <ian at hixie.ch> wrote:
> On Thu, 17 Jun 2004, Jim Ley wrote:
> > Could you address the other points About re-serialisation of the DOM
> > leading to something radically different from what was intended (the
> > attribute should only be there if there was also an event listener
> > after a re-serialisation and parse it wouldn't be there.)
> 
> This is a general problem with event handlers -- any document using script
> will have different behaviour if you remove all the event handlers.
> 
> For example, if you take the following HTML4 fragment:
> 
>   <form> <button> Test </button> </form>
> 
> ...the behaviour will be radically different if, when the fragment was
> serialise, the <form> element had an event listener that cancelled any
> "submit" events.

but that behaviour is "nothing" which is bad, but it's better than the
WF2 suggestion which would give you an attribute of
onrecieved="chicken" which is likely to error, I'm sure there's a much
better proposal about (just using an attribute to signifiy if it's
allowed or not, set if there's a listener listening etc.)

> I fail to see how an issue tracker would improve matters in this respect.

Oh right, I do, since everything would have a "this is issue # X and
we can easily see that it was addressed, and how it was addressed."

> the point above about reserialisation isn't relevant since, as
> described above, it is an issue with event listeners as a whole, not with
> the onreceived="" attribute).

No, since we're forced in your WF2 to put an attribute in, which
doesn't make sense unless the script exists but does exist then,
normally with Event listeners if the script doesn't exist neither do
any of the dependant attributes, with this method we have the
dependant attributes, but no script to handle it.

> If you think I skipped a comment by mistake, I urge you to reraise the
> issue (as you did here, and as one would have to do with an issue
> tracker).

But I'll generally know when you don't respond to mine, I don't know
when you don't respond to other peoples issues, and they may be highly
relevant, but I can't know, if we have an issue tracker we can see
that the open issues exist.

Jim.