# [00:00] <chaals> ... will note that parsers may only deal with characters up to a certain range.
# [00:00] <chaals> RESOLUTION: Change keyIdentifier to key and keyLocation to location (and see if it breaks anything)
# [00:00] <shepazu> topic: feature detection and fallbacks (featurestrings?)
# [00:01] <chaals> DS: I am sympathetic to Garrett's call for feature detection for feautures, but not sure how to do it and have seen resistance from browers
# [00:01] <chaals> OP: Would be great but I ahven't seen a reasonable proposal and don't have a good one.
# [00:02] <chaals> DS: You could get this by defining feature strings for each event (e.g. hasFeature('events#wheel')
# [00:02] <chaals> ... would not be backwartds compatible, but could be a basis for moving forward
# [00:02] <chaals> OP: would not work with greasemonkey scripts or similar
# [00:03] <chaals> DS: True. Nor plugins, unless you build in a way for a script to register an event type.
# [00:03] <smaug> the reason mentioned on the mailing few weeks ago
# [00:03] <chaals> ... but even so, most browsers won't have extensions/plugins/... that add event functionality
# [00:04] <chaals> ... that have to be sent to the browser.
# [00:04] <chaals> ... seems like having it would be better than nothing if browsers supporte it moving forward?
# [00:05] <chaals> TL: From a binary standpoint, IE has two ways of hooking events. An event sync (which we are removing for performance), and a connection point interface, used for the control to fire its own events into the browser
# [00:06] <chaals> ... it is more like a callback system. no event is sent, you use addEventListener to register a name you know, and when you throw your event we map your name to your callback. Those events neve collide with system events.
# [00:06] <chaals> ... until we get HTML+JS extensibility model there is no need to know what events you support
# [00:07] <chaals> DS: even failing for browser extensions of various kinds, the number of authors served by saying "does this browser support foo? Or should I fall back to older behaviour?"
# [00:07] <chaals> ... planning to write a script library for D3E (as far as possible)
# [00:08] <chaals> ... so people can code to it no matter what their browser. Detecting if a browser claimed to support something would be really useful.
# [00:08] <chaals> OP: Could be useful in some cases
# [00:08] <chaals> DS: It won't be universally useful - will be false +ve and -ve but I will go ahead and put in feature strings for each event.
# [00:08] * Zakim sees no one on the speaker queue
# [00:10] <chaals> CMN: The argument against it is that as you get into a wider range of browsers and browser types, the value drops below the cost.
# [00:11] <chaals> DS: If we have a specific means to detect stuff, and a browser lies, there is a rationale to call them out in public and say stop that.
# [00:11] * Zakim sees chaals on the speaker queue
# [00:12] <chaals> DS: If you do this by event type, there is a much wider range of useful information that comes from the feature string tha if it is from an interface.
# [00:12] <chaals> ... there will be failures, but there always are
# [00:13] <chaals> TL: THe difference is that existing object level detection is already fine grained with property checking. Events don't have a property in the same way
# [00:13] <chaals> ... seems like there is value in having one API that tells you something about the UA, and lets you detect features.
# [00:14] <chaals> ... browsers have hasFeature, and if you get a useful answer that's ok, but if you get a false +/-ve then you do what you are already doing going into deeper testing.
# [00:14] <chaals> DS: Doesn't help with code paths but helps with building script libraries etc.
# [00:14] <chaals> TL: Doing this will be useful over time.
# [00:15] <chaals> DS: The mistake in SVG was to make the hasFeature too coarse-grained, so it was too hard to use it efficiently.
# [00:16] <chaals> ... now we want to support it at the attribute-for-an-element level.
# [00:16] <chaals> ... it isn't like you need to store a bunch of strings, just know that when you implement a new event you expose it to hasFeature. They are compositional
# [00:16] <chaals> ... so I will put that in, and we will see what happens
# [00:20] <chaals> CMN: When people register, it woudl be really helpful to say whether you are going for widgets or APIs since the WG is split into two rooms.
# [00:23] <shepazu> Another important thing to remember is that onresize does not bubble.
# [00:23] <chaals> ... we were talking about not letting it target element. Events for arbitrary elements should not be allowed to bubble... (and for window it doesn't make much difference)
# [00:27] <chaals> TL: if we do that we might need to do the load-like magic... maybe
# [00:27] <chaals> DS: Maybe I have general text that says some events for legacy reasons have different flow and these will be noted in the host language
# [00:27] <chaals> OP: Currently that is just load