W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2010

Minutes: DOM3 Events Telcon, 28 August 2010

From: Doug Schepers <schepers@w3.org>
Date: Wed, 29 Sep 2010 23:53:12 -0400
Message-ID: <4CA409A8.6040802@w3.org>
To: "www-dom@w3.org" <www-dom@w3.org>
Here are the minutes from the Web Applications WG DOM3 Events 
teleconference of 28 August 2010:

Chair: Doug Schepers
scribe: Travis Leithead
scribeNick: Travis
smaug_: http://www.w3.org/2008/webapps/track/issues/
shepazu: http://www.w3.org/2008/webapps/track/products/2

Agenda: http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0144.html


Topic: input/keyboard locale
trackbot: ISSUE-119 -- Consider adding input/keyboard locale to text and 
keyboard events -- raised
trackbot: http://www.w3.org/2008/webapps/track/issues/119
shepazu: Not clear before that this was a requirement for this spec.
... Does not appear to be difficult to implement
smaug_: Linux could be a problem, this info may not be exposed..
shepazu: For platforms that do expose this info, it doesn't seem like it 
would be difficult to implement
.. Depending on the platform, it may not be available/dependable.
... May not be accurate in all scenarios.
... as a heuristic, content authors are willing to say good enough.
Travis: We can spec it such that if the platform/OS doesn't support 
providing this info, then the value could be null (n/a)
smaug_: Where is the keyboard layouts defined?
shepazu: Couldn't find a standard for reporting the keyboard 
layout--also couldn't find something for the keybaord language.
... I could have an English Dvorak keyboard!
... For the language, I think we should just go with en-US style
... (Can't think of the term for this format)
... BCP47 tag
smaug_: shepazu: 
http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0138.html
shepazu: BCP-47 tag (e.g. "en-US")
Travis: Notes that "navigator.systemLanguage" returns a similar language 
code: "en-us"
shepazu: Probably requires a list of conversions from OS-defined 
langauge codes to BCP-47
... (normalized)
Travis: Related to the issue, I have a preference that the keyboard lang 
info be provided as a global property (on document?) and that we create 
an event that notifies of changes (which are not expected to occur very 
frequently)
shepazu: http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0141.html
Travis: Not sure I understand the threat.
shepazu: It allows profiling of users
Travis: I would argue that the navigator object allows a higher-degree 
of profling (see navigator.platform in HTML5)
... Also, my goal is to limit the amount of information we provide in 
the event that is largely redundant.
shepazu: If you copy/paste something, the input-locale could be 
different than if the user is just typing text.
travis: good point.
shepazu: In order to specify this correctly... consider:
... when something is copied, is the source language prerved?
s/prerved/preserved/
... does this impose a requirement on an OS?
Travis: What's the scope?
smaug_: TextInput and Keyboard events.
shepazu: Sounds like we have accepted this comment.
RESOLUTION: Accept issue 119, and add inputLocale to TextInput and 
Keyboard events.


Topic: Issue 120 move scroll from UIEvent to Event
shepazu: I think it logically belongs in UI events, even if it 
traditionally hasn't been a UIEvent, I don't see how it breaks.
... it might be argued that is sends extraneous information (null/ empty 
string)
... Any code that characterizes events based on its interface, it makes 
more sense to make it a UIEvent.
... Makes it consistent with our model.
Travis: I have no argument for or against this issue.
smaug_: Same here.
shepazu: It is a non-goal for me to document the behavior as it exists 
in browsers today.
... my goal is to create a consistent and logical model that forms a 
solid foundation for future events and content.
... Since the folks on the call don't have a strong opinion, then I'd 
like to keep this event the way it is.
RESOLUTION: Keep scroll as a UIEvent, pending further feedback from 
implementors


Topic: Issue 121: generalize textInput to cover all user-initiated changes
Note: Jacob Rossi joins the call from Travis' phone
shepazu: This sounds like mutation events.
JRossi: textInput sounded like the catch-all for input, without the rest 
of this requests in the Issue.
Travis: Notes that the "input" event exists that covers more of these 
cases (removals of characters, addition of characters, etc.)
shepazu: I'm interested in deferring this request, and not doing this in 
DOM L3 Events.
... I'd like to propose that we keep it the way it is for now. If we 
decide to accept this workitem, that it could be a standalone spec that 
adds the new event and details the new event exhaustively, it's 
relationship to textInput, etc.
... By adding it into this spec, we may not get the implementation 
feedback that we've had so far.
... Based on the details of how this new event would be speced, it could 
be compared to textInput.
JRossi: Could we consider changing the name? from textInput to beforeInput.
Travis: This event is already implemented (for some time) in WebKit and 
now in IE9.
shepazu: On the surface this proposal (Issue 212) seems pretty complex 
(with lots of cases).
RESOLUTION: counter-propose that the beforeInput event be a separate 
event that is defined in its own spec.


Topic: Issue 122 add mousewheel event back.
Travis: The mousewheel event was originally pulled from this spec 
because we (Microsoft) felt that mousewheel didn't 1) convey all the 
information that was appropriate for a future-looking wheel event, 2) 
scenarios covered by mosuewheel are also covered by wheel event, 3) 
implementation support for mousewheel is spotty (not available in 
Mozilla's Firefox).
smaug_: mousewheel doesn't have all the features.
JRossi: only one-direction scrolling, doesn't handle pixel/line/etc.
... Also confusing from a consistency (intra-spec) to have both events.
shepazu: A lot of existing content special-cases mousewheel and other 
wheel-related events.
... If we specified it, and browsers changed their implementations, 
existing content might break.
... better to let it fade with time and exist in specific 
implementations idiosyncratic-ly. (known spelling issue <---)
RESOLUTION: The group will not re-add mousewheel event back to the spec.


Topic: Issue 126: isTrusted
smaug_: I believe we used 'trusted' because of alignment with XBL2
Travis: 'trusted' has the same semantic meaning as 'isTrusted'.
RESOLUTION: Change 'trusted' to 'isTrusted'


Topic: Plans for TPAC
shepazu: Wondering who's attending.
... Please register as quickly as possible if you are planning on 
attending!!!!!j
Received on Thursday, 30 September 2010 03:53:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:05 GMT