Closed dontcallmedom closed 1 year ago
WebKit used DeviceOrientationOrMotionPermissionState
. A bit elaborate, but to the point. Any other suggestions?
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.
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.
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.
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.
Discussed at TPAC 2019 F2F. Resolved to adopt the PermissionState enum from the Permissions API specification.
I've sent https://github.com/w3c/deviceorientation/pull/88 to fix this.
The spec defines an enum with the name
PermissionState
- this conflicts with the name used in the Permission API.