- From: David Bruant <bruant.d@gmail.com>
- Date: Mon, 21 Jul 2014 18:19:40 +0200
- To: Boris Zbarsky <bzbarsky@MIT.EDU>, www-dom@w3.org
Le 21/07/2014 17:49, Boris Zbarsky a écrit : > On 7/21/14, 10:20 AM, David Bruant wrote: >> Very much like symbols can be used as property names, I believe they >> should be usable as event names. > > Will that be backwards-compatible with code that operates on > event.name on events today? (I assume you mean event.type) hmm... good question. I obviously don't have a definite answer, but some elements make me hopeful. For such code to break, it would need to be faced with events which is symbole-named. This cannot happen via addEventListener (since it's currently impossible to listen to events with a symbol name). For such code to break, the code would then need to override the native addEventListener and have some code which assumes the event name to be a string. This assumption can be true, but in most cases, event names are only used for equality (directly with === or indirectly as property name to find the relevant listeners, but neither case can cause breakage with symbols). This assumption can lead to a breakage if the code reads the string, for instance to search for a prefix. Some libraries have conventions like "change:blabla" for event names. But they also usually reimplement their own event system, so that wouldn't be a cause for a breakage. Above, I started the reasoning with addEventListener, because the DOM doesn't have, for instance, a mechanism to listen to all events of a given object (which would probably break more easily if symbols came along). So in conclusion, code that would break is overriding Event.prototype.addEventListener and reading the string, for instance to find a prefix. This sounds unlikely enough... but I've seen less horrors on the web than you have, so I'm usually more optimistic about these things :-) I briefly looked at jQuery [1] to see if it was using event.type. It does only to do === on it or as property key (that's obviously only the latest version, I didn't look at other versions, but imagine the story is the same). jQuery doesn't override addEventListener as far as I know either. I briefly looked at Flight [2] too given it heavily relies on DOM events for component communication and found the same thing. These are, of course, well-maintained libraries, not necessarily representing what's on the web. David [1] https://github.com/jquery/jquery/blob/master/src/event.js [2] https://github.com/flightjs/flight/blob/master/lib/base.js
Received on Monday, 21 July 2014 16:20:12 UTC