IRC log of webapps on 2009-09-23

Timestamps are in UTC.

21:07:09 [RRSAgent]
RRSAgent has joined #webapps
21:07:09 [RRSAgent]
logging to
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:+ 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]
21:08:36 [Zakim]
21:08:50 [Zakim]
21:09:15 [Zakim]
21:09:27 [Zakim]
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]
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]
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]
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]
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]
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]
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:
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 &, 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]
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]
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]
21:52:32 [chaals]
TL: The HTML5 parsing spe has a hard limit on codepoint when doing character conversion.
21:53:08 [shepazu]
21:53:17 [Travis]
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]
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]
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]
22:35:42 [Zakim]
22:35:50 [Zakim]
22:35:51 [Zakim]
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]
22:38:27 [shepazu]
trackbot, stop telcon
22:38:27 [trackbot]
Sorry, shepazu, I don't understand 'trackbot, stop telcon'. Please refer to 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 trackbot
22:38:41 [trackbot]
RRSAgent, bye
22:38:41 [RRSAgent]
I see 1 open action item saved in :
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