Minutes, DOM3 Events Telcon, 1 December 2010

(forgot to send these before)

IRC log of webapps on 2010-12-01

http://www.w3.org/2010/12/01-webapps-irc
Meeting: Web Applications Working Group Teleconference, DOM3 Events
Date: 01 December 2010
Attendees: jrossi, Travis, smaug_, shepazu

shepazu: Let's talk larger scope...
... start 2nd last call in Jan?
... not expecting large changes coming other than issues raised
... should have a story around mutation events (where they will be)
... should try to have a FPWD of new mutation events spec ready to point to
https://github.com/jeresig/nodelist
see ".added(function), .removed( function)"
RESOLUTION: Contact JResig for using NodeList as a replacement for 
mutation events (to get it on a W3C standards track).
smaug_: We should ensure that DOMCharacterDataModified scenarios are 
handled as they are one of the most important.
shepazu: It might be that not all scenarios for mutation events fit into 
the same mold; we shouldn't feel like they must all fit.
scribe: Travis
scribeNick: Travis
shepazu: We've now started working on the Web Events WG.
... will cover both touch events and "high level" events.
... will likely resurrect "activate" in such a "high level" spec.
... realizes that not all browser vendors can join this group at this time.
... all browsers _are_ in the PF WG, so looking to have "high level" 
event spec as a joint-delieverable.
[shepazu]: 
http://www.w3.org/MarkUp/Forms/Group/Drafts/1.1/intent-based-events.html

Topic: Back to DOM L3 Events
shepazu: Making some prose updates to unify info on keyboard events
... Up next: integrating keyboard language info
jrossi: We'd like to focus on the keyboard language property and "3rd 
parameter to addEventListener being optional"
jrossi: IE9 updated to make this 3rd parameter optional, in part due to 
some sites not providing the parameter.
smaug_: Apparently this was a bug in chrome that is now relied on in 
actual web pages :(
shepazu: I don't have a strong opinion either way
smaug_: I don't really like it, but its OK to make it optional.
RESOLUTION: make the 3rd parameter to 
addEventListener/removeEventListener optional

shepazu: smaug_ what are your priorities?
smaug_: Nothing is high priority as FF4 won't have many of these spec 
updates in it.
shepazu: Else from MS?
jrossi: Yes, we have a suggestion on keyboard locale info.
[smaug_]: great
...and sorry
jrossi: We're OK putting a property on an event, and skipping the static 
property.
... For TextInput event, we're not sure we can identify an input locale 
for the various input types that are possible.
... We recommend moving the property from TextInput to CompositionEvent
... Pasted content (for example) could have content from multiple 
locales in it.
shepazu: We could put it in all three...
... It's an implementation problem-- 3 implementations across mutliple 
OS's might not be able to support it.
smaug_: Could we have KeyboardEvent and CompositionEvent have the property?
shepazu: Your argument makes sense
... We don't know of OS's that support it [identifying locale 
information for random text input]
... OK. Seems compelling to me. Esp.
RESOLUTION: Add "inputlocale" to KeyboardEvent and CompositionEvent (but 
not TextInput)
jrossi: How about simply "locale"?
... (It's simpler)
shepazu: OK.
smaug_: TextInput has "inputMethod", we could have "inputLocale" to be 
consistent.
shepazu: Will Microsoft send their comment to the list in response to 
this thread?
jrossi: Yes, will do.

Travis: Where are we on LC comments?
if there is still anything else, please ping me
shepazu: Prior to TPAC we reviewed the list; I don't think we have a lot 
of new issues.
Travis: RAISED=44, OPEN=7, PENDINGREVIEW=1
... 112 CLOSED
shepazu: Oh, one more thing (to talk about next week)...
... keyCode/charCode/which
shepazu: Until next week!
... send any related documentation my way

Received on Wednesday, 15 December 2010 23:33:55 UTC