Rick Byers

Ok so to be concrete, the one-off proposal (using today's WebIDL) is something like: Option A: ``` webidl interface EventTarget { ... static readonly attribute EventListenerOptions EventListenerOptions; } ``` With...

Sure, but what if we add a string option like `class` (as Anne proposed). We want to re-use the dictionary type, right? I'd be fine just defining that case to...

> What I mean is that the object that IDL dictionaries define on the global is purely for feature-testing purposes. It is not an instance of the dictionary in question...

Yeah I know, I'm just trying to come up with a path for shipping this for `EventListenerOptions` ASAP (since we're actively getting people to adopt it) without necessarily blocking on...

Sorry I missed your first ping. We ship this API in chromium and it has [significant usage](https://chromestatus.com/metrics/feature/timeline/popularity/1098) but AFAIK no other engine has expressed interested in implementing it. That may...

See request to migrate to UI Events here: https://github.com/w3c/uievents/issues/108

FWIW It [looks like](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/events/UIEvent.cpp&sq=package:chromium&type=cs&l=65&rcl=1436211521) the prototype blink implementation does clear sourceDevice in this case.

Probably the main question here is what the property name should be. Ideas: - draggingScrolls - pointerMovementScrolls - scrollByDragging

I think it should be scroll-specific. Eg. I think the SPen can scroll but not zoom (and if not, certainly it would be reasonable for some pens to act that...

Note that it's tempting to describe this as "is direct manipulation" - i.e. is the input metaphor one where the user is directly grabbing things on the screen. I think...