PermissionState is already defined in Permission API about deviceorientation HOT 7 CLOSED

WebKit used DeviceOrientationOrMotionPermissionState. A bit elaborate, but to the point. Any other suggestions?

from deviceorientation.

is there any reason not to re-use PermissionState as defined in the permission API? I understand prompt is not a value that would be returned, but since it's in the control of the UA in any case, I'm not sure it matters to have too broad an enum.

from deviceorientation.

Loop in @cdumez to comment on WebKit implementation. @reillyeon for Chromium.

Implementations that ship with permissions.query() would indeed benefit from enum value prompt, while WebKit without query() would still stay compliant with its current implementation even if PermissionState would be re-used.

from deviceorientation.

I don't really have an opinion here. The name of the enum is not Web-exposed so changing it to whatever would be fine. WebKit does not support for permission API but reusing PermissionState from that spec would equally be fine and would also not require any code change on our side. Note that technically, I copied the Notification API and that one does not use the enum from the Permission API either:
https://notifications.spec.whatwg.org/#enumdef-notificationpermission

It does use a less generic name for the enum though.

from deviceorientation.

Thanks @cdumez for confirming WebKit would be fine with this spec re-using the PermissionState
enum from the Permissions API.

Chromium CL (not merged) defines DeviceOrientationPermissionState. FYI @rakuco, the proposal in discussion is to add a third state prompt to the enum.

This issue is now on the F2F agenda.

from deviceorientation.

Discussed at TPAC 2019 F2F. Resolved to adopt the PermissionState enum from the Permissions API specification.

https://www.w3.org/2019/09/19-dap-minutes.html#x15

from deviceorientation.

I've sent #88 to fix this.

from deviceorientation.