- From: Rick Byers <notifications@github.com>
- Date: Mon, 02 May 2016 08:05:36 -0700
- To: w3c/webcomponents <webcomponents@noreply.github.com>
- Cc:
- Message-ID: <w3c/webcomponents/issues/486/216261537@github.com>
> It's still a little weird, and special casing touch events will be too, but I guess there's no great way around that. Yeah there may not be any clean way around special-casing the dispatch of touch events here. That's what blink's implementation has to do already ([EventPath::adjustForTouchEvent](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/events/EventPath.cpp&sq=package:chromium&type=cs&l=294&rcl=1462173394)), so I guess it's not too surprising to require some parallel complexity in the spec. It's an interesting question to ask whether an event with multiple logical related elements is an inherently bad DOM event design or not. There are some reasons why this approach to handling multi touch is better for developers and for performance than (eg.) dispatching a separate event per touch point (like Pointer Event do), but it's quite debatable. /cc @tkent-google @dtapuska --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/webcomponents/issues/486#issuecomment-216261537
Received on Monday, 2 May 2016 15:06:03 UTC