If 'InputDevice' isn't about the device itself, but about its capabilities, rename the interface?

[smaug----]

If 'InputDevice' isn't about the device itself, but about its capabilities, should the interface be renamed?
Like InputDeviceCapabilities and then UIEvent could have something like
InputDeviceCapabilities? sourceCapabilities = null;

This way one doesn't immediately expect the interface to have something like
readonly attribute DOMString type; // mouse, pen ...

[RByers]

The least 'capability-like' API suggested in the brainstorming doc is 'isCurrentlyOnScreen' (for virtual keyboards). That's more like 'state' than 'capabilities', but seems pretty close.

So I'm OK with "InputDeviceCapabilities" and "sourceCapabilities" if that's the consensus. @patrickhlauke @jacobrossi @garykac @tdresser @summerww any opinion?

[RByers]

Also +@mbrubeck since he contributed to the original design discussion here on the TECG call

[garykac]

DeviceCapabilities sounds good to me.

If we do that, I think that it makes sense to remove DeviceClass entirely.
That'll eliminate the problem of what to do about devices that fit into
multiple categories.

If something like the class is still desirable, then I'd prefer something
like hasKeyboardCapabilites, hasTouchScreenCapabilities, et al., since this
would allow devices to belong to multiple classes.

On Thu, Aug 6, 2015 at 4:08 AM, Rick Byers notifications@github.com wrote:

The least 'capability-like' API suggested in the brainstorming doc
https://docs.google.com/document/d/1WLadG2dn4vlCewOmUtUEoRsThiptC7Ox28CRmYUn8Uw/edit#heading=h.o7qaw089pyqp
is 'isCurrentlyOnScreen' (for virtual keyboards). That's more like 'state'
than 'capabilities', but seems pretty close.

So I'm OK with "InputDeviceCapabilities" and "sourceCapabilities" if
that's the consensus. @patrickhlauke https://github.com/patrickhlauke
@jacobrossi https://github.com/jacobrossi @garykac
https://github.com/garykac @tdresser https://github.com/tdresser
@summerww https://github.com/SummerWW any opinion?

—
Reply to this email directly or view it on GitHub
https://github.com/RByers/InputDevice/issues/19#issuecomment-128213924.

[patrickhlauke]

+1 to making the name less ambiguous and more about capabilities. if we do want something state-like (as in the keyboard example), maybe calling it characteristics, rather than capabilities, which would perhaps cover the second case as well?

[tdresser]

This approach also implies that testing equality isn't meaningful. Intuitively, I'd expect that if the sourceDevice of two events is the same, then they came from the same physical input device. I wouldn't assume this with sourceCapabilities.

LGTM!

[RByers]

Thanks everyone!

@garykac I don't think we can use DeviceCapabilities since there's already a W3C spec that uses that class name for system-wide capabilities. InputDeviceCapabilities has some nice symmetry with that though.

So concrete proposal is:

• Rename InputDevice to InputDeviceCapabilities
• Rename sourceDevice to sourceCapabilities

Let's keep the discussion open for another day or two, then @Summerlw says she will do the renames (spec, polyfill, tests, and blink implementation).

[RByers]

Done