- From: Doug Schepers <schepers@w3.org>
- Date: Wed, 23 Sep 2009 18:43:45 -0400
- To: "www-dom@w3.org" <www-dom@w3.org>
Hi, Folks-
The minutes for the DOM3 Events telcon of Wednesday, 23 Sept 2009 can be
found here:
http://www.w3.org/2009/09/23-webapps-minutes.html
Or as text below:
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Web Applications Working Group Teleconference
23 Sep 2009
[2]Agenda
[2] http://www.w3.org/mid/4ABA6384.9020108@w3.org
See also: [3]IRC log
[3] http://www.w3.org/2009/09/23-webapps-irc
Attendees
Present
Shepazu, mauro, chaals, smaug, travis
Regrets
Chair
shepazu
Scribe
chaals
Contents
* [4]Topics
1. [5]Initialising events
2. [6]Dropping event namespace init methods
3. [7]focusin/focusout, mouseenter/mouseleave, and
detectability
4. [8]key identifiers and convertKeyIdentifier
5. [9]feature detection and fallbacks (featurestrings?)
6. [10]TPAC
7. [11]Resize event
8. [12]Meeting time
* [13]Summary of Action Items
_________________________________________________________
<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
[14]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:
[15]http://java.sun.com/docs/books/tutorial/i18n/text/string.html
[15] 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> [16]http://javascript.about.com/library/blunicode.htm
[16] 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>
[17]http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Event
s.html#glossary-unicode-code-point
[17]
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>
[18]https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/O
bjects/String/charCodeAt
[18]
https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Objects/String/charCodeAt
<Travis>
[19]https://developer.mozilla.org/en/Core_JavaScript_1.5_Guide/Unico
de
[19]
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>
[20]http://www.w3.org/mid/6eeb8bd10906241911l191c6710va55d7ddbd86399
f7@mail.gmail.com
[20]
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 [21]http://www.w3.org/2005/06/tracker/irc
for help
[21] http://www.w3.org/2005/06/tracker/irc
<shepazu> trackbot, end telcon
Summary of Action Items
[NEW] ACTION: Doug to post something to the list on focusin/out and
mouseenter/leave on event names [recorded in
[22]http://www.w3.org/2009/09/23-webapps-minutes.html#action01]
Received on Wednesday, 23 September 2009 22:43:59 UTC