See also: IRC log
<trackbot> Date: 23 September 2009
<scribe> scribe: chaals
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
... 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
... 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...
DS: Talked to other team members
... asked them what general tenor in groups is.
... nobody had a problem with dropping them
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
... 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
... 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
OP: The change of namespace mutation event is a different beast - please don't kill it
... Moved focus to its own interface. will probably add from and to to the interface
... 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?
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
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
... 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].
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?
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
DS: I couldn't figure out how to
get charCodeAt to gve me the unicode codepoint in FF when I
... 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?
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.
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
... 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)
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.
... 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
... 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
... 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
... 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
... 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
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.
TL: OP, you were thinking about the event not bubbling...
<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)
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
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> 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
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/wy/why/ Succeeded: s/FFFF/10FFFF/ Found Scribe: chaals Inferring ScribeNick: chaals Default Present: Shepazu, mauro, chaals, smaug, travis Present: Shepazu mauro chaals smaug travis Agenda: http://www.w3.org/mid/4ABA6384.firstname.lastname@example.org Found Date: 23 Sep 2009 Guessing minutes URL: http://www.w3.org/2009/09/23-webapps-minutes.html People with action items: doug[End of scribe.perl diagnostic output]