Re: Event constructor defaults

On Mon, Feb 11, 2013 at 9:12 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Mon, Feb 11, 2013 at 2:58 PM, Glenn Maynard <glenn@zewt.org> wrote:
> > Unfortunately, this is already implemented in Firefox and Chrome, but
> > changing these defaults might still be still web-compatible.
>
> It's not compatible with the initEvent() API however.


I'd rather have good defaults than compatibility with an API with bad
defaults, at least in this case.

(By the way, I didn't know initEvent even had defaults.  It doesn't in the
spec or in Firefox, but apparently does in WebKit.)

Not sure why
> there would not be a reason to have a uncancellable event. Making
> cancelable indicate whether preventDefault() can actually be used
> seems like a net positive.


It's like passing a flag into a function that prevents it from returning
"false".  It has no practical use.  But I'm just talking about defaults:
you should have to explicitly say if you want to disable preventDefault,
not that you want to enable it.

And often canceling events has no effect
> (certainly with platform events). The non-bubbling will be a non-issue
> once we have better event listeners.
>

The "always bubbles" workaround won't make events not bubbling when they
should a non-issue.  It's a workaround to allow event delegation to be used
on events that intentionally don't bubble.  That doesn't mean it doesn't
matter if events don't bubble when they should.  You should have to
explicitly say that you don't want your event to bubble, not that you do
want it to.

-- 
Glenn Maynard