21:07:09 <RRSAgent> RRSAgent has joined #webapps
21:07:09 <RRSAgent> logging to http://www.w3.org/2009/09/23-webapps-irc
21:07:11 <trackbot> RRSAgent, make logs public
21:07:11 <Zakim> Zakim has joined #webapps
21:07:13 <trackbot> Zakim, this will be WAPP
21:07:13 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
21:07:14 <trackbot> Meeting: Web Applications Working Group Teleconference
21:07:14 <trackbot> Date: 23 September 2009
21:07:20 <chaals> zakim, code?
21:07:20 <Zakim> sorry, chaals, I don't know what conference this is
21:07:27 <shepazu> zakim, this will be DOM3
21:07:27 <Zakim> ok, shepazu; I see IA_WebApps(DOM3)5:00PM scheduled to start 7 minutes ago
21:07:31 <chaals> zakim, code?
21:07:31 <Zakim> the conference code is 3663 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), chaals
21:07:36 <shepazu> zakim, call shepazu 
21:07:36 <Zakim> ok, shepazu; the call is being made
21:07:37 <Zakim> IA_WebApps(DOM3)5:00PM has now started
21:07:38 <Zakim> +Shepazu
21:08:36 <Zakim> +mauro
21:08:50 <Zakim> +mauro.a
21:09:15 <Zakim> -mauro
21:09:27 <Zakim> +??P0
21:09:30 <shepazu> zakim, mauro.a is chaals 
21:09:30 <Zakim> +chaals; got it
21:09:36 <smaug> Zakim, ??P0 is me
21:09:36 <Zakim> +smaug; got it
21:10:15 <chaals> zakim, mute me
21:10:15 <Zakim> chaals should now be muted
21:10:49 <chaals> scribe: chaals
21:10:55 <chaals> chair: shepazu
21:11:31 <shepazu> agenda: http://www.w3.org/mid/4ABA6384.9020108@w3.org 
21:11:56 <chaals> Topic: Initialising events
21:12:24 <chaals> DS: Suggestion is to either deprecate (or drop or shove away from the spotlight) event initialisers like initMouseEvent
21:12:54 <chaals> ... One idea: between creating and dispatching an event the properties would be writeable, to save remembering long unwieldy parameter patterns.
21:13:01 <chaals> ... Smaug, you didn't like it. Why?
21:13:26 <chaals> OP: Changing attributes to read/write feels odd.
21:13:43 <chaals> ... but the init methods are awkward, so maybe OK.
21:14:08 <chaals> DS: Right. The init* are already awkward. Making them writeable is more extensible than adding parameters
21:14:11 <chaals> OP: Yes.
21:14:16 <chaals> q+
21:14:35 <chaals> OP: We would then need to define default values for unitialised properties.
21:14:48 <chaals> DS: So we would allow that and define for what? each event?
21:15:00 <chaals> OP: Yes, for each event... or maybe each interface.
21:15:03 <chaals> ack me
21:16:33 <chaals> CMN: We only need to define non-optionals. And we coul just say "if the required attributes aren't met then we just throw away the event"
21:16:52 <chaals> OP: Type is the only property that must be set. everything else should have some reasonable default value.
21:17:18 <chaals> DS: Right now we create an event interface, and then initialise an event and say what you want.
21:17:44 <smaug> var e = new Event("scroll");
21:17:45 <chaals> ... strikes me as really awkward. Why not say 'createEvent("foobar")'
21:18:05 <smaug> var e = new MouseEvent("click");
21:18:06 <chaals> ... each event type knows what its interface is
21:18:14 <chaals> zakim, mute me
21:18:14 <Zakim> chaals should now be muted
21:18:43 <chaals> OP: You can create a click event that implements the normal interface
21:18:48 <chaals> DS: Why is that useful
21:18:54 <chaals> OP: It isn't. It is just there
21:20:21 <chaals> DS: If your chief objetion was that making attributes writeable was odd, but we agree that so is initialisers, I prefer to go with the one that doesn't reqire an nitialiser. Init event would still work where it is defined, but I would not define it for new events.
21:20:27 <chaals> OP: What about creating events?
21:20:43 <chaals> DS: I will propose something about creating events by type rather than by interface.
21:20:53 <chaals> OP: Can you still overwrite type?
21:21:19 <chaals> ... you need a way to create a specific interface, or an object that implements it, then set a type identified in the spec, because people use their own events.
21:21:38 <chaals> ... that is why creating mouseevent by saying new mouseEvent(type) should work.
21:21:50 <chaals> DS: OK, we should look at that further...
21:22:24 <shepazu> Topic: Dropping event namespace init methods
21:22:37 <chaals> ack me
21:22:55 <chaals> DS: Talked to other team members about this
21:23:00 <chaals> zakim, please mute me
21:23:00 <Zakim> chaals should now be muted
21:23:10 <chaals> ... asked them what general tenor in groups is.
21:23:19 <chaals> ... nobody had a problem with dropping them
21:23:22 <chaals> OP: OK.
21:23:55 <chaals> DS: While they have some hope (a namespace can be just another attribute), I am proposing dropping methods devoted to namespaced events
21:24:07 <chaals> OP: You then need to define how event listeners work with namespaces.
21:24:31 <chaals> DS: Uploaded a draft that removes most *NS versions of methods. What about addEventListenerNS ?
21:24:37 <chaals> ... proposing to drop that too.
21:24:47 <chaals> OP: So namespace disappears from the spec?
21:25:11 <chaals> DS: It is all through the spec. In those places, and in mutation events if someone changes the namespace of an attribute you can change that.
21:25:19 <chaals> OP: There is the NS URI still in there?
21:25:28 <Zakim> +[Microsoft]
21:25:34 <chaals> ... if you drop NSlistener the namespace URI in the event doesn't mean anything
21:25:42 <chaals> DS: So how far do we want to go with this?
21:26:00 <chaals> zakim, [Microsoft] is travis
21:26:00 <Zakim> +travis; got it
21:26:08 <chaals> TL: Drop 'em.
21:26:21 <chaals> DS: So checking that you think it makes sense to remove all namespaces...
21:26:30 <chaals> TL: Even if you put them back in, we will not implement them.
21:26:40 <chaals> DS: So it makes sense to drop them
21:26:58 <chaals> TL: Just saying, if you bring them back, it will take *at least* another release to get them in.
21:27:05 <chaals> ... can see Xforms complaining...
21:27:10 <Travis> Travis has joined #webapps
21:27:27 <chaals> DS: Asked, and the team contacts said nobody would seriously complain. IT is not clear content uses them, ...
21:27:36 <chaals> TL: We shouldn't be tied to the drafts...
21:27:47 <chaals> DS: Sure, although we should respect people who were trying to do the right thing
21:28:01 <chaals> RESOLUTION: Drop namespaced events
21:28:18 <chaals> agenda+ TPAC
21:28:21 <shepazu> Topic: focusin/focusout, mouseenter/mouseleave, and detectability 
21:28:59 <chaals> OP: The change of namespace mutation event is a different beast - please don't kill it
21:29:02 <chaals> DS: Right.
21:29:31 <chaals> DS: Moved focus to its own interface. will probably add from and to to the interface
21:29:34 <chaals> OP: wy?
21:29:38 <chaals> s/wy/why/
21:29:48 <chaals> ... is that what IE has?
21:30:06 <chaals> ack me
21:30:19 <chaals> zakim, mute me
21:30:19 <Zakim> chaals should now be muted
21:30:40 <chaals> DS: It is. Garrett says detectability of that element might be very mportant to content.
21:31:27 <chaals> TL: Nobody will use focusin/out, they will use onfocusin/out. So there is a possibility that a website tries all events from IE, which might break, but it doesn't seem like a big deal.
21:31:48 <chaals> ... if youdon't support all the other properties IE has, it will still break. SO design it the way you want it to be.
21:32:06 <chaals> DS: Garrett suggested we should name the events differently to avoid breaking content
21:32:08 <chaals> q+
21:32:21 <chaals> ... e.g. focusenter/leave to match mouse...
21:32:42 <chaals> TL: there wa another discussion asking focusin/out to bubble. Do they bubble today?
21:32:46 <chaals> DS: yes
21:32:58 <chaals> OP: the problem is with focus/blur not bubbling
21:33:16 <chaals> TL: We need to make a rpincipled decision - are these being added for compatibility or some other purpose?
21:33:33 <chaals> DS: Doesn't seem like they will be compatible, but they are useful for the characteristics they have
21:33:35 <chaals> OP: Agree
21:33:44 <chaals> DS: So changing the name is not such a problem
21:34:00 <chaals> OP: ditto mouseenter/leave
21:34:09 <chaals> DS: Don't think they have the same problem
21:34:10 <ArtB> ArtB has joined #webapps
21:34:27 <chaals> OP: All event listeners use the same properties, (IE) not DOM properties.
21:34:39 <chaals> DS: We are really going for functionality, not just compatibility.
21:35:39 <chaals> OP: The new functioanlity is useful
21:35:49 <chaals> DS: People are arguing against adding new functionality...
21:35:52 <chaals> TL: like us
21:36:16 <chaals> TL: for the toEleement/from, I don't care
21:36:29 <chaals> DS: If we don't add them, people can detect if they exist and act accordingly.
21:36:50 <chaals> TL: A scenario. I want to support old IE and a new browser ith focusin/out.
21:37:22 <chaals> ... my code has to switch between addeventlistener and attachevent. In both cases I can use focusin. so now I register in both browsers, the event fires and a listener gets it.
21:38:05 <chaals> ... now I have to write code that detects (e.g.) toElement to see if this is an IE browser and use it, otherwise I assume that relatedTarget is there and use it. Otherwise, if we made the names the same, I could just use them.
21:38:40 <chaals> OP: there are other properties in IE in any case
21:38:42 <chaals> ack me
21:39:29 <chaals> CMN: Travis' example still holds...
21:39:32 <chaals> zakim, mute me
21:39:32 <Zakim> chaals should now be muted
21:39:49 <chaals> ... if ou are doing the same thing, wy force people to branch - leave that for where there are different functionalities
21:39:56 <chaals> TL: Garrett has a point...
21:40:11 <chaals> DS: it is a little more code to maintain for browsers. But not much. Maybe we should take this to the list
21:40:36 <chaals> ... think Garrett certainly has a point worth exploring. I won't change the spec now, but willing to entertain the notion that we should.
21:40:45 <chaals> TL: I don't have a strong opinion yet...
21:41:09 <chaals> OP: I think the best solution for content authors is to rename the events.
21:41:24 <chaals> DS: I am fine with that. Would it apply to both focus* and mouse*?
21:41:29 <chaals> TL: Maybe both.
21:41:44 <chaals> OP: Please post it to the list so we can think about it more with more input
21:42:09 <chaals> ACTION: Doug to post something to the list on focusin/out and mouseenter/leave on event names
21:42:10 <trackbot> Created ACTION-407 - Post something to the list on focusin/out and mouseenter/leave on event names [on Doug Schepers - due 2009-09-30].
21:42:20 <shepazu> Topic: key identifiers and convertKeyIdentifier 
21:42:23 <chaals> TL: I can see it applying to mouse* - it makes our stories consistent
21:42:42 <chaals> DS: Anne / Maciej asked why we are doing the strings the way they are?
21:42:49 <chaals> zakim, mute me
21:42:49 <Zakim> chaals was already muted, chaals
21:43:24 <chaals> ... I asked PLH why they were like that and he said he doesn't think there was any particular reason.  don't know if it means something in Java - is it javascript only or universal?
21:43:35 <chaals> TL: THink it works like that in C# in a string literal
21:44:01 <chaals> DS: Then it is probably like that in Java. Where is this defined - per language, or is there some external spec?
21:44:09 <chaals> TL: Should check Java and see what they have
21:44:58 <chaals> DS: No objection to doing the / - in many cases it makes more sense. I still think there will be times when people want to get teh unicode value (codepoint), although I am having trouble articulating a use case.
21:45:24 <chaals> ... if you have a virtual keyboard and want to say what the unicode codepoint is. I think there will be cases where someone wants the codepoint.
21:45:32 <chaals> TL: Can you turn that into an HTML identity?
21:45:43 <Travis> \u is supported in Java: http://java.sun.com/docs/books/tutorial/i18n/text/string.html
21:45:45 <chaals> DS: Added a convenience constant to turn things into entities
21:46:25 <chaals> ... makes a numeric entity. Wouldn't change something to &amp;, it would change it to &2342; (or whatever)
21:46:28 <chaals> TL: That's useful
21:47:12 <chaals> DS: Not sure if there is a way of doing that now in JS. If you can get the codepoint you can make the entity, because that is a string operation. But if we do make a helper method, we may as well add more of what we thing will be useful functionality.
21:47:34 <chaals> ... converting to an entity, extracting codepoint as string, ...
21:48:09 <chaals> ... If I have the shift key, it doesn't have a Unicode representation. It's named. So if I said charAt for that it will give me the same as S.
21:48:40 <chaals> ... something running around my head says we don't want to use charCodeAt, we want a helper function - either keyname or code point or whatever.
21:49:04 <chaals> TL: looking at a JS/unicode site. /u is supported natively in JS
21:49:31 <Travis> http://javascript.about.com/library/blunicode.htm
21:49:37 <chaals> DS: I couldn't figure out how to get charCodeAt to gve me the unicode codepoint in FF when I tested.
21:49:51 <chaals> ack me
21:50:04 <chaals> zakim, mute me
21:50:04 <Zakim> chaals should now be muted
21:50:43 <chaals> DS: Looks useful (except it doesn't work for me)
21:50:57 <chaals> OP: Do we want to support things over the 64k limit?
21:51:12 <chaals> DS: Maciej doesn't see the use case for supporting those - they are not on keyboards
21:51:15 <chaals> OP: Are we sure?
21:51:39 <smaug> http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#glossary-unicode-code-point
21:51:42 <chaals> DS: I don't know, and don't know it will stay that way. Seems like an artificial limit and not sure why we should limit people that way.
21:52:13 <chaals> OP: In the spec now, the limit is FFFF
21:52:29 <shepazu> s/FFFF/10FFFF
21:52:32 <chaals> TL: The HTML5 parsing spe has a hard limit on codepoint when doing character conversion.
21:53:08 <shepazu> https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Objects/String/charCodeAt
21:53:17 <Travis> https://developer.mozilla.org/en/Core_JavaScript_1.5_Guide/Unicode
21:54:42 <chaals> DS: I think encapsulating this in a helper function would be useful. It is a unicode helper that also knows about named keys. So you could use things beyond key events to resolve this stuff into entitites, etc.
21:55:19 <chaals> ... this is just about making things more user-friendly. I am going to resist not putting this in...
21:55:38 <chaals> ... let's define helpers that people might find, and then see what happens.
21:56:41 <chaals> DS: One other aspect. We call the attribute KeyIdentifier. I think nobody likes that... and I don't want to say "key". At the same time once it is propogated I think people will understand.
21:57:04 <chaals> ... waht about having "key" as the attribute?
21:57:09 <chaals> TL: no conflicts?
21:57:15 <chaals> DS: Apparently not...
21:57:20 <chaals> TL: So simple...
21:57:28 <chaals> OP: What about "key" and "location"
21:57:53 <chaals> DS: Let's try it and see what happens
21:58:12 <chaals> RESOLUTION: We will use the escape sequence for value for keyname
21:58:33 <chaals> RESOLUTION: We will try to describe a helper function for conversion
21:58:38 <chaals> TL: The one specced out now?
21:59:10 <chaals> DS: Same general idea. Right now we have characer value and unicode string. we are dropping unicode string and making character value an escape sequence
22:00:11 <chaals> ... will note that parsers may only deal with characters up to a certain range.
22:00:31 <chaals> RESOLUTION: Change keyIdentifier to key and keyLocation to location (and see if it breaks anything)
22:00:50 <shepazu> topic: feature detection and fallbacks (featurestrings?) 
22:01:36 <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
22:01:50 <chaals> OP: Would be great but I ahven't seen a reasonable proposal and don't have a good one.
22:02:15 <chaals> DS: You could get this by defining feature strings for each event (e.g. hasFeature('events#wheel')
22:02:29 <chaals> ... would not be backwartds compatible, but could be a basis for moving forward
22:02:45 <chaals> OP: would not work with greasemonkey scripts or similar
22:03:08 <chaals> [scribe missed reasoning]
22:03:27 <chaals> DS: True. Nor plugins, unless you build in a way for a script to register an event type.
22:03:34 <smaug> the reason mentioned on the mailing few weeks ago 
22:03:58 <chaals> ... but even so, most browsers won't have extensions/plugins/... that add event functionality
22:04:11 <chaals> ... that have to be sent to the browser.
22:04:34 <chaals> ... seems like having it would be better than nothing if browsers supporte it moving forward?
22:05:24 <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
22:06:08 <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.
22:06:32 <chaals> ... until we get HTML+JS extensibility model there is no need to know what events you support
22:07:20 <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?"
22:07:34 <chaals> ... planning to write a script library for D3E (as far as possible)
22:08: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.
22:08:17 <chaals> OP: Could be useful in some cases
22:08:43 <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.
22:08:46 <chaals> ack me
22:10:53 <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.
22:11:17 <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.
22:11:20 <chaals> q+
22:12:46 <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.
22:12:55 <chaals> ... there will be failures, but there always are
22:13:23 <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
22:13:27 <chaals> zakim, mute me
22:13:27 <Zakim> chaals should now be muted
22:13:57 <chaals> ... seems like there is value in having one API that tells you something about the UA, and lets you detect features.
22:14:35 <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.
22:14:50 <chaals> DS: Doesn't help with code paths but helps with building script libraries etc.
22:14:59 <chaals> TL: Doing this will be useful over time.
22:15:56 <chaals> DS: The mistake in SVG was to make the hasFeature too coarse-grained, so it was too hard to use it efficiently.
22:16:25 <chaals> ... now we want to support it at the attribute-for-an-element level.
22:16:52 <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
22:17:01 <chaals> ... so I will put that in, and we will see what happens
22:17:02 <chaals> ack me
22:18:53 <chaals> RESOLUTION: We will add per-event-type feature string algorithm, and see what happens.
22:19:25 <chaals> zakim, mute me
22:19:25 <Zakim> chaals should now be muted
22:19:59 <chaals> DS: If something answers hasFeature to blah then it is clear it is the IE IE model
22:20:00 <chaals> ack me
22:20:04 <chaals> Topic: TPAC
22:20:42 <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.
22:22:18 <chaals> Topic: Resize event
22:22:35 <chaals> TL: OP, you were thinking about the event not bubbling...
22:23:08 <shepazu> http://www.w3.org/mid/6eeb8bd10906241911l191c6710va55d7ddbd86399f7@mail.gmail.com
22:23:18 <shepazu> [[
22:23:20 <shepazu> Another important thing to remember is that onresize does not bubble.
22:23:20 <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)
22:23:21 <shepazu> ]]
22:23:39 <chaals> ... or keeping it as is but removing elementTarget
22:23:47 <chaals> OP: and add somethig new for elements?
22:23:52 <chaals> TL: yeah, in a later spec.
22:24:06 <chaals> zakim, mute me
22:24:06 <Zakim> chaals should now be muted
22:25:09 <chaals> OP: So when resize fires on IE at document, does it go to document or window?
22:25:14 <chaals> TL: body, I think...
22:25:26 <chaals> OP: What if body element is resized but not the document?
22:25:32 <chaals> TL: then I think we fire it.
22:25:49 <chaals> OP: thnking of making a similar mess to load event...
22:26:39 <chaals> TL: If we need that for existing site compat it would probably be the best. I haven't tried it
22:26:51 <chaals> DS: Should we say resize does not bubble?
22:26:55 <chaals> OP: OK with that
22:27:12 <chaals> TL: if we do that we might need to do the load-like magic... maybe
22:27:36 <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
22:27:45 <chaals> OP: Currently that is just load
22:27:49 <chaals> DS: Might be resize too
22:28:01 <chaals> OP: What about just making resize not bubble. What will break?
22:28:08 <chaals> DS: OK, fine by me.
22:28:24 <chaals> ... I should still allow the odd event flow for load, which can defer to HTML5
22:28:28 <chaals> ack me
22:29:16 <chaals> RESOLUTION: resize will not bubble
22:29:37 <chaals> Topic: Meeting time
22:29:59 <chaals> DS: This time is not so good for Smaug, Chaals. Could we move it a couple of hours earlier?
22:30:06 <chaals> OP: 3 hours earlier was good.
22:30:15 <chaals> TL: that's fine.
22:30:25 <chaals> CMN: That's better than 2 hours earlier for me.
22:35:39 <Zakim> -travis
22:35:42 <Zakim> -smaug
22:35:50 <Zakim> -Shepazu
22:35:51 <Zakim> -chaals
22:35:51 <Zakim> IA_WebApps(DOM3)5:00PM has ended
22:35:52 <Zakim> Attendees were Shepazu, mauro, chaals, smaug, travis
22:37:15 <smaug> "mauro" :)
22:38:19 <shepazu> heh
22:38:27 <shepazu> trackbot, stop telcon
22:38:27 <trackbot> Sorry, shepazu, I don't understand 'trackbot, stop telcon'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
22:38:39 <shepazu> trackbot, end telcon
22:38:39 <trackbot> Zakim, list attendees
22:38:39 <Zakim> sorry, trackbot, I don't know what conference this is
22:38:40 <trackbot> RRSAgent, please draft minutes
22:38:40 <RRSAgent> I have made the request to generate http://www.w3.org/2009/09/23-webapps-minutes.html trackbot
22:38:41 <trackbot> RRSAgent, bye
22:38:41 <RRSAgent> I see 1 open action item saved in http://www.w3.org/2009/09/23-webapps-actions.rdf :
22:38:41 <RRSAgent> ACTION: Doug to post something to the list on focusin/out and mouseenter/leave on event names [1]
22:38:41 <RRSAgent>   recorded in http://www.w3.org/2009/09/23-webapps-irc#T21-42-09