gcs

Thanks. Yeah, it does make sense that you wouldn't want to do that work up front if you weren't sure it was going to be necessary. As I alluded to earlier though this is for a game framework, which is a case where you do generally know in advance exactly what features are needed. That said, even the game frameworks I've looked at (which generally do a lot of feature detection up front) don't do event normalization up front, even though it's known in advance that it will be needed. Maybe it's just that event normalization 'on demand' is so common that people tend to do it that way by default,

Doing it all in one place would be a 'pro' for me, architecturally at least. Performance isn't much of a concern because whether the work is done up-front or on a per-event basis, it's not likely to be a bottleneck. The reason doing it up front is appealing to me is that all other feature detection (canvas, audio, WebGL, Web Audio, and so on) is done up front, and it'd be nice if event properties could be done there also. In the given context there won't be multiple page loads (this is for a canvas-based game framework), so I don't think that will be an issue. This is actually what

Most JavaScript frameworks I've looked at that deal with input events (like jQuery) normalize events by checking for the presence of various properties when the event is received. It seems though it should be possible to determine in advance what properties to use by using event creation, e.g. (exception logging omitted for brevity): var mouseButtonPropertyToUse = "button";var event = null;if (typeof MouseEvent === "function") { event = new MouseEvent("");} else { try { event = document.createEvent("MouseEvent"); } catch (exception) { try { event = document.createEvent("MouseEven