- From: Rick Byers <rbyers@google.com>
- Date: Fri, 7 Jun 2013 13:46:41 -0400
- To: "public-pointer-events@w3.org" <public-pointer-events@w3.org>
- Message-ID: <CAFUtAY-VajUbvuyudMZA4+TQzK5QpBARz0PmfTywHyz2ushd=Q@mail.gmail.com>
Below is a quick update after our discussion in the call last week about jQuery / Google colaboration on pointer events polyfills. We'll have more regular discussion on the polymer mailing list ( https://groups.google.com/forum/?fromgroups=#!forum/polymer-dev), but Scott and I will give occasional updates to the WG here. We'd love to have involvement from anyone else in the community who is interested on the GitHub project: https://github.com/Polymer/PointerEvents. Eg. please give the existing polyfill a try and file issues for things that don't work properly. Thanks, Rick ---------- Forwarded message ---------- From: Rick Byers <rbyers@google.com> Date: Fri, Jun 7, 2013 at 1:42 PM Subject: [PointerEvents] Notes from jQuery/Microsoft/Google hangout on Polymer pointer events polyfill To: polymer-dev@googlegroups.com Cc: Scott González <scott.gonzalez@gmail.com>, "Scott Blomquist (MS OPEN TECH)" <sblom@microsoft.com>, Dave Methvin <dave.methvin@gmail.com>, Kris Borchers <kris.borchers@gmail.com>, Daniel Freedman <dfreedm@google.com> Today several of us (cc'd) from jQuery, Microsoft and Google met to discuss how we can pool our efforts at building a pointer events polyfill that can be used as broadly as possible, while being maximally spec compliant. We feel the polymer PointerEvents project is probably the best place to start (being the most production ready / performance conscious of the existing polyfills). The biggest challenge will be adding support for IE6 (as required by jQuery core), but Daniel is willing to take patches for this and will do some refactoring to make it easier. We will use the GitHub project issue tracker ( https://github.com/Polymer/PointerEvents/issues) to track our work, and (for now anyway) the polymer-dev mailing list with a [PointerEvents] prefix for discussion (with occasional updates to the W3C pointer events working group). Below are my rough notes from the meeting. Thanks everyone - I'm excited for what we can accomplish together here! Rick - All agree we'd like to have a common code base that gets as close as possible to implementing the standard Pointer Events API, while also being suitable for use in production - We know there will be tough trade-offs here while we wait for browser native support - We will push the key trade-offs to the developer, let them choose between maximal spec compliance and maximum performance - Areas known not to conform to spec - touch-action as attribute - makes dynamic changes possible - touch-action scroll - pointer capture may not be complete - instanceof says MouseEvent instead of PointerEvent (hassle, won't work on IE) - button/buttons values not correct - State of testing - Dave has pointer events tests TTWF event - Had bug to try to use spec tests, Daniel wants to make it a priority. We'll try to figure out how to share as much testing as possible (including for any native implementation pieces in blink) - Daniel using Kharma to spawn up all the browsers - Chrome, Chrome Canary, Firefox - Tests in tree should work against the Kharma runner - ideally pull requests would have been run against them and continue to pass Tests in tree should work against the Kharma runner - ideally pull requests would have been run against them and continue to pass - Mailing list? - Use Polymer list, with [PointerEvents] - If that doesn't work we'll create a new list - Document caveats for users - bugs are probably best for now - README kind of a pain - stable and master branch makes 3-way merges tricky - At some point we may want to create a longer document with a list of all the issues and work-arounds - IE6 support - Daniel - ideally have a separate build or debug load that loads extra file, eg. that uses attachEvent - Ideally won't have IE6 branch/fork, in the repo but loaded only when you need it - On IE6-9 it's only mouse->pointer we need to worry about (no touch support), should make it a lot easier - Daniel: planning on splitting touch and mouse code into separate files, shouldn't be too hard - Also need to patch how pointer events are actually made (use Object.defineProperty etc.) - Need to turn of mutation observer calls, eg. mock that just doesn't explode - Scott: will need to use fireEvent instead of dispatchEvent - Kris may start working on this - use Function.bind all over the place - Pointer capture relies on modifying Element.prototype which won't work on IE6 - Use flagging system on event objects (relying on a polyfill for WeakMap) - Use of Node.contains - shouldn't be a big deal - Opera 12 - doesn't have mutation observers - PointerEvents polyfill already has an API to update touch-actions using querySelector (just not document), and also 'setTouchAction' to explicitly set it on an element - dynamic updates should be rare for most consumers, but jQuery may do it a bunch. - If a site/framework wants to rely on dynamic update on a browser without mutation observers, it will have to explicitly tell the polyfill after there has been an update - Polyfill has support for Shadow DOM when it's present, but shadow DOM polyfill requires IE10, so shouldn't be an issue - Next steps - Daniel will split apart touch and mouse portions first (have a bit of a complicated interaction for synthesized mouse events for touch). - jQuery (Scott G/Kris) will sign the Polymer CLA and start looking at changes they need for old IE - Scott B will talk to the various people at Microsoft involved in pointer events polyfills and follow up with their plan for going forward. - Rick will continue to work to get touch-action supported natively n Chrome (behind the experimental flag for now), and will update the polyfill to take advantage of it when present
Received on Friday, 7 June 2013 17:47:29 UTC