Web Applications Working Group Teleconference -- 23 Sep 2009

<trackbot> Date: 23 September 2009

<scribe> scribe: chaals

Initialising events

DS: Suggestion is to either deprecate (or drop or shove away from the spotlight) event initialisers like initMouseEvent
... One idea: between creating and dispatching an event the properties would be writeable, to save remembering long unwieldy parameter patterns.
... Smaug, you didn't like it. Why?

OP: Changing attributes to read/write feels odd.
... but the init methods are awkward, so maybe OK.

DS: Right. The init* are already awkward. Making them writeable is more extensible than adding parameters

OP: Yes.
... We would then need to define default values for unitialised properties.

DS: So we would allow that and define for what? each event?

OP: Yes, for each event... or maybe each interface.

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"

OP: Type is the only property that must be set. everything else should have some reasonable default value.

DS: Right now we create an event interface, and then initialise an event and say what you want.

<smaug> var e = new Event("scroll");

DS: strikes me as really awkward. Why not say 'createEvent("foobar")'

<smaug> var e = new MouseEvent("click");

DS: each event type knows what its interface is

OP: You can create a click event that implements the normal interface

DS: Why is that useful

OP: It isn't. It is just there

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.

OP: What about creating events?

DS: I will propose something about creating events by type rather than by interface.

OP: Can you still overwrite type?
... 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.
... that is why creating mouseevent by saying new mouseEvent(type) should work.

DS: OK, we should look at that further...

Dropping event namespace init methods

DS: Talked to other team members about this
... asked them what general tenor in groups is.
... nobody had a problem with dropping them

OP: OK.

DS: While they have some hope (a namespace can be just another attribute), I am proposing dropping methods devoted to namespaced events

OP: You then need to define how event listeners work with namespaces.

DS: Uploaded a draft that removes most *NS versions of methods. What about addEventListenerNS ?
... proposing to drop that too.

OP: So namespace disappears from the spec?

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.

OP: There is the NS URI still in there?
... if you drop NSlistener the namespace URI in the event doesn't mean anything

DS: So how far do we want to go with this?

TL: Drop 'em.

DS: So checking that you think it makes sense to remove all namespaces...

TL: Even if you put them back in, we will not implement them.

DS: So it makes sense to drop them

TL: Just saying, if you bring them back, it will take *at least* another release to get them in.
... can see Xforms complaining...

DS: Asked, and the team contacts said nobody would seriously complain. IT is not clear content uses them, ...

TL: We shouldn't be tied to the drafts...

DS: Sure, although we should respect people who were trying to do the right thing

RESOLUTION: Drop namespaced events

focusin/focusout, mouseenter/mouseleave, and detectability

OP: The change of namespace mutation event is a different beast - please don't kill it

DS: Right.
... Moved focus to its own interface. will probably add from and to to the interface

OP: why?
... is that what IE has?

DS: It is. Garrett says detectability of that element might be very mportant to content.

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.
... if youdon't support all the other properties IE has, it will still break. SO design it the way you want it to be.

DS: Garrett suggested we should name the events differently to avoid breaking content
... e.g. focusenter/leave to match mouse...

TL: there wa another discussion asking focusin/out to bubble. Do they bubble today?

DS: yes

OP: the problem is with focus/blur not bubbling

TL: We need to make a rpincipled decision - are these being added for compatibility or some other purpose?

DS: Doesn't seem like they will be compatible, but they are useful for the characteristics they have

OP: Agree

DS: So changing the name is not such a problem

OP: ditto mouseenter/leave

DS: Don't think they have the same problem

OP: All event listeners use the same properties, (IE) not DOM properties.

DS: We are really going for functionality, not just compatibility.

OP: The new functioanlity is useful

DS: People are arguing against adding new functionality...

TL: like us
... for the toEleement/from, I don't care

DS: If we don't add them, people can detect if they exist and act accordingly.

TL: A scenario. I want to support old IE and a new browser ith focusin/out.
... 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.
... 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.

OP: there are other properties in IE in any case

CMN: Travis' example still holds...
... if ou are doing the same thing, wy force people to branch - leave that for where there are different functionalities

TL: Garrett has a point...

DS: it is a little more code to maintain for browsers. But not much. Maybe we should take this to the list
... think Garrett certainly has a point worth exploring. I won't change the spec now, but willing to entertain the notion that we should.

TL: I don't have a strong opinion yet...

OP: I think the best solution for content authors is to rename the events.

DS: I am fine with that. Would it apply to both focus* and mouse*?

TL: Maybe both.

OP: Please post it to the list so we can think about it more with more input

<scribe> ACTION: Doug to post something to the list on focusin/out and mouseenter/leave on event names [recorded in http://www.w3.org/2009/09/23-webapps-minutes.html#action01]

<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].

key identifiers and convertKeyIdentifier

TL: I can see it applying to mouse* - it makes our stories consistent

DS: Anne / Maciej asked why we are doing the strings the way they are?
... 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?

TL: THink it works like that in C# in a string literal

DS: Then it is probably like that in Java. Where is this defined - per language, or is there some external spec?

TL: Should check Java and see what they have

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.
... 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.

TL: Can you turn that into an HTML identity?

<Travis> \u is supported in Java: http://java.sun.com/docs/books/tutorial/i18n/text/string.html

DS: Added a convenience constant to turn things into entities
... makes a numeric entity. Wouldn't change something to &, it would change it to &2342; (or whatever)

TL: That's useful

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.
... converting to an entity, extracting codepoint as string, ...
... 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.
... 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.

TL: looking at a JS/unicode site. /u is supported natively in JS

<Travis> http://javascript.about.com/library/blunicode.htm

DS: I couldn't figure out how to get charCodeAt to gve me the unicode codepoint in FF when I tested.
... Looks useful (except it doesn't work for me)

OP: Do we want to support things over the 64k limit?

DS: Maciej doesn't see the use case for supporting those - they are not on keyboards

OP: Are we sure?

<smaug> http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#glossary-unicode-code-point

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.

OP: In the spec now, the limit is 10FFFF

TL: The HTML5 parsing spe has a hard limit on codepoint when doing character conversion.

<shepazu> https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Objects/String/charCodeAt

<Travis> https://developer.mozilla.org/en/Core_JavaScript_1.5_Guide/Unicode

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.
... this is just about making things more user-friendly. I am going to resist not putting this in...
... let's define helpers that people might find, and then see what happens.
... 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.
... waht about having "key" as the attribute?

TL: no conflicts?

DS: Apparently not...

TL: So simple...

OP: What about "key" and "location"

DS: Let's try it and see what happens

RESOLUTION: We will use the escape sequence for value for keyname
... We will try to describe a helper function for conversion

TL: The one specced out now?

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
... will note that parsers may only deal with characters up to a certain range.

RESOLUTION: Change keyIdentifier to key and keyLocation to location (and see if it breaks anything)

feature detection and fallbacks (featurestrings?)

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

OP: Would be great but I ahven't seen a reasonable proposal and don't have a good one.

DS: You could get this by defining feature strings for each event (e.g. hasFeature('events#wheel')
... would not be backwartds compatible, but could be a basis for moving forward

OP: would not work with greasemonkey scripts or similar

[scribe missed reasoning]

DS: True. Nor plugins, unless you build in a way for a script to register an event type.

<smaug> the reason mentioned on the mailing few weeks ago

DS: but even so, most browsers won't have extensions/plugins/... that add event functionality
... that have to be sent to the browser.
... seems like having it would be better than nothing if browsers supporte it moving forward?

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
... 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.
... until we get HTML+JS extensibility model there is no need to know what events you support

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?"
... planning to write a script library for D3E (as far as possible)
... so people can code to it no matter what their browser. Detecting if a browser claimed to support something would be really useful.

OP: Could be useful in some cases

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.

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.

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.
... 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.
... there will be failures, but there always are

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
... seems like there is value in having one API that tells you something about the UA, and lets you detect features.
... 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.

DS: Doesn't help with code paths but helps with building script libraries etc.

TL: Doing this will be useful over time.

DS: The mistake in SVG was to make the hasFeature too coarse-grained, so it was too hard to use it efficiently.
... now we want to support it at the attribute-for-an-element level.
... 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
... so I will put that in, and we will see what happens

RESOLUTION: We will add per-event-type feature string algorithm, and see what happens.

DS: If something answers hasFeature to blah then it is clear it is the IE IE model

TPAC

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.

Resize event

TL: OP, you were thinking about the event not bubbling...

<shepazu> http://www.w3.org/mid/6eeb8bd10906241911l191c6710va55d7ddbd86399f7@mail.gmail.com

<shepazu> [[

<shepazu> Another important thing to remember is that onresize does not bubble.

TL: 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)

<shepazu> ]]

TL: or keeping it as is but removing elementTarget

OP: and add somethig new for elements?

TL: yeah, in a later spec.

OP: So when resize fires on IE at document, does it go to document or window?

TL: body, I think...

OP: What if body element is resized but not the document?

TL: then I think we fire it.

OP: thnking of making a similar mess to load event...

TL: If we need that for existing site compat it would probably be the best. I haven't tried it

DS: Should we say resize does not bubble?

OP: OK with that

TL: if we do that we might need to do the load-like magic... maybe

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

OP: Currently that is just load

DS: Might be resize too

OP: What about just making resize not bubble. What will break?

DS: OK, fine by me.
... I should still allow the odd event flow for load, which can defer to HTML5

RESOLUTION: resize will not bubble

Meeting time

DS: This time is not so good for Smaug, Chaals. Could we move it a couple of hours earlier?

OP: 3 hours earlier was good.

TL: that's fine.

CMN: That's better than 2 hours earlier for me.

<smaug> "mauro" :)

<shepazu> heh

<shepazu> trackbot, stop telcon

<trackbot> Sorry, shepazu, I don't understand 'trackbot, stop telcon'. Please refer to http://www.w3.org/2005/06/tracker/irc for help

<shepazu> trackbot, end telcon

- DRAFT -

Web Applications Working Group Teleconference

23 Sep 2009

Attendees

Contents