Minutes, DOM3 Events Telcon, 6-10-2010

Meeting: DOM3 Events Teleconference
Date: 06 October 2010

scribe: Travis
scribeNick: Travis

shepazu: A few small changes have been made to the spec, but it's not 
been uploaded on the site yet.

Topic: Last Call Issue review
Hmm, I was filtered on "open"...
[1:10pm] smaug_: http://www.w3.org/2008/webapps/track/products/2 has 
quite a few issues
Issue 1: I propose to resolve as fixed.
Issues raised since last call (summary)
Issue 119: input/keyboard locale (we agreed to do that) -- need a 
concrete proposal
shepazu: ... Will just incorporate what's in the feedback.
jrossi: In my analysis of use-cases, generally, it's more important to 
know what the locale is _before_ getting an event.
... Therefore, it may be better to have the state available for retrieval
... also, the state doesn't change that often.
shepazu: How do you cover the scenario where copy/paste from another locale?
jrossi: Acording to our developers on IE, the keyboard locale 
information is not conveyed as part of the copy/paste system (in 
Windows). Therefore, that scenario just isn't possible on a 
Windows-based OS.
shepazu: Hmm. True. Though an OS could change...
... Second issue with that proposal (of more concern to me): By allowing 
the browser to get your locale, it's yet another fingerprinting 
heurisitic that browser vendors are trying to crack-down on.
... From a privacy standpoint, my concern is around yet more passive 
information exposed to script.
jrossi: System locale (vs. keyboard locale) is already exposed in script 
in major browsers.
smaug_: My system locale is en_US, though my keyboard locale is Finnish 
(so there's less info exposed today).
shepazu: Folk's concerns are that this [keyboard locale state-based 
property] adds yet one more piece of info into the fingerprinting reveal
... Trying to think through use-cases....
... Let's assume there's a method to get the locale.
... (keyboard locale)
jrossi: It we had this property on keyboard/input, would we leak this 
through dispatchEvent?
Travis: No, it would have the empty string (because it wasn't initialized)
shepazu: initKeyboardEvent would have a way to provide an initial value
... A browser could have a policy where the value (state value) isn't 
exposed until the keyboard is used.
... They could also have a user-facing privacy setting to turn off 
keyboard locale.
... (and other locale settings)
... If we wanted to distinguish between keyboard and paste events, we 
could have both methods (the static getter and provide the data on the 
event)
smaug_: Thinking about specific event flows...
... first time the user uses the keyboard, the event should have some locale
... Then if the user changes the keyboard locale, an event could also be 
fired.
... (correction to the above: first time the keyboard is used, we could 
fire an event that contains the keyboard locale as well)
(All: general agreement...)
shepazu: Since we're talking about state, does this make sense to have a 
new interface with potentially other state on it?
travis: There's another working group doing something similiar with 
system state and events (a System API spec?)
shepazu: If we do this, we probably shouldn't hand it over to another 
group, as we really need to satisfy our Last Call comment and this is 
really needed for internationalization.
Travis: Given that simply adding the keyboard locale to the keyboard 
event/input event follows a well-established pattern in this spec, and 
that doing it the other way (using a state property and change 
notification) is a new pattern in this spec, AND given that there are 
privacy concerns for providing the state property, my conclusion is to 
go with original proposal in the mail.
shepazu: Don't have a strong feeling either way, but my inclination is 
to go with what was suggested in the Raised issue.
jrossi: No objections.
smaug_: Yeah.
shepazu: Issue 120 - not doing that.
... Issue 121 - recommend doing this in another spec.
... Issue 122 - not doing that.
... Issue 123: Rationale for feature strings
jrossi: In some cases user agents may claim support but not actually 
support all the events.
shepazu: This really comes down to an different approaches in feature 
detection
... explicit feature detection (asking the implementation)
... Modernizr is one approach
... Specs generally have a provision for hasFeature, and though it's not 
usually dependable it has a long and honorable tradition
... Detecting particular events can be hard/difficult (you have to get a 
trusted event to know for sure)
... With our more discrete feature strings, implementations (like IE9) 
can start reporting exactly what events are supported.
Travis: FIRE ALARM!
Travis: See ya!

Received on Thursday, 7 October 2010 21:11:52 UTC