<plh> https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html status of the editor's draft
garykac: we hadn't moved locale and getKeyboardState into D3E because they required more spec work. ... we also knew that keyboard locale was underspecified. ... there was one other thing... <garykac> See the Input Device API Sketch : https://docs.google.com/document/d/1WLadG2dn4vlCewOmUtUEoRsThiptC7Ox28CRmYUn8Uw/edit garykac: specifically: <garykac> Section: "What information should be supplied for keyboards?" <garykac> It was suggested that there should a sourceDevice field in the events. garykac: I think the immedate problem is the difference between real touch vs. synthesized touch. Seems like 'isTrusted' is the answer to that. garykac: Browsers have created "fake" mouse events when some touch events happen--trying to find the 'real' events. Should we fork off the old UIEvents to continue to develop those concepts, or fold them into D3E/UIEvents? garykac: I really don't want to put the old UIEvents content back--it would slow us down. plh: Trying to understand ... shelf old UI Events as a note ... but give someone else the option of picking it up in the future? ... if someone started working on it later, would it go into the new UIEvents, or something else? garykac: if they wanted 'locale' it might go to the spec that Rik is proposing. ... for queryKeyCap, it's more nebulous ... could go anywhere plh: Whoever wanted to pick it up would need to figure out how to move it forward. garykac: Yes, we can solve that problem later. I think publishing as a note reflects they way things are. garykac: are there practical implications to leaving active vs. publishing as a note. plh: would the note be the current contents of UIEvents (old)? garykac: yes, minus the boilerplate. plh: Would someone write that up, and let me know? I can then take the next step? garykac: It should say: This was originally part of the original D3E spec which we've shelved for now, as we don't have time to work out the details of 'locale' and other features may be subsumed by a [potential] input events spec plh: That's sufficient, thanks! ... I'll let you know what phraseology I come up with and then go from there. garykac: We can still fix as many bugs as possible, but this is a good time to re-publish (with the new name). ... we'd rather do this sooner than later. <plh> https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html <plh> should be http://www.w3.org/TR/uievents/ <plh> (instead of http://www.w3.org/TR/UI-Events/) I think we are then ready to re-publish D3E/UIEvents. (Gary is fixing the bug in the header, so that the link to the latest published version is updated.) <garykac> The link in the header is fixed to point to w3.org/tr/uievents/ looking at bugs garykac: 27991 - looks like we need a spot to clarify this in the spec ... maybe resolved with just a note?
