PermissionState is already defined in Permission API

[dontcallmedom]

The spec defines an enum with the name PermissionState - this conflicts with the name used in the Permission API.

[anssiko]

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

[dontcallmedom]

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.

[anssiko]

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.

[cdumez]

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.

[anssiko]

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.

[reillyeon]

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

[foolip]

I've sent #88 to fix this.