anssiko has just submitted a new pull request for https://github.com/w3c/deviceorientation: == Fix the build == None See https://github.com/w3c/deviceorientation/pull/153 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
anssiko has just submitted a new pull request for https://github.com/w3c/deviceorientation: == Fix the build == None See https://github.com/w3c/deviceorientation/pull/153 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
anssiko has just submitted a new pull request for https://github.com/w3c/deviceorientation: == Fix the build == None See https://github.com/w3c/deviceorientation/pull/153 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
I think this also concerns the Permissions Policy integration, even if tangentially. Permissions Policy integration does not fall under the same _"a web app should not be able to distinguish between the user rejecting permission to use a sensor/capability, and the sensor/capability not being present"_ TAG guideline, but most other specs throw a DOM exception like NotAllowedError when a Permissions Policy check fails, whereas this specification just avoids firing any events. Both Blink and WebKit seem to do this at the moment, but WebKit had to add a workaround for at least one domain affected by this behavior: https://github.com/WebKit/WebKit/blob/09ad6a20c559b27ada2b2e8bf859dc90930fb23f/Source/WebCore/page/LocalDOMWindow.cpp#L2194 -- GitHub Notification of comment by rakuco Please view or discuss this issue at https://github.com/w3c/deviceorientation/issues/148#issuecomment-2020382882 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
marcoscaceres has just submitted a new pull request for https://github.com/w3c/deviceorientation: == Chore auto-publish.yml: update WG decision URL == Closes #151 See https://github.com/w3c/deviceorientation/pull/152 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
marcoscaceres has just submitted a new pull request for https://github.com/w3c/deviceorientation: == Chore auto-publish.yml: update WG decision URL == Closes #151 See https://github.com/w3c/deviceorientation/pull/152 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
marcoscaceres has just submitted a new pull request for https://github.com/w3c/deviceorientation: == Chore auto-publish.yml: update WG decision URL == Closes #151 See https://github.com/w3c/deviceorientation/pull/152 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
marcoscaceres has just submitted a new pull request for https://github.com/w3c/deviceorientation: == Chore auto-publish.yml: update WG decision URL == Closes #151 See https://github.com/w3c/deviceorientation/pull/152 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
marcoscaceres has just submitted a new pull request for https://github.com/w3c/deviceorientation: == Chore auto-publish.yml: update WG decision URL == Closes #151 See https://github.com/w3c/deviceorientation/pull/152 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@marcoscaceres, can you take a look? -- GitHub Notification of comment by reillyeon Please view or discuss this issue at https://github.com/w3c/deviceorientation/pull/149#issuecomment-2011014307 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@marcoscaceres, can you take a look? -- GitHub Notification of comment by reillyeon Please view or discuss this issue at https://github.com/w3c/deviceorientation/pull/149#issuecomment-2011014307 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
anssiko has just created a new issue for https://github.com/w3c/deviceorientation: == Fix the build == The build is broken, here's how to fix it: When [this CfC](https://www.w3.org/mid/5B0AEC39-28EC-473D-AA8F-802C7FEF3798@intel.com) passes on 26 March 2024, use the manual publication process. That should fix the build and automated publication workflow. Context: https://github.com/w3c/deviceorientation/pull/142#issuecomment-1993819279 Please view or discuss this issue at https://github.com/w3c/deviceorientation/issues/151 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
anssiko has just created a new issue for https://github.com/w3c/deviceorientation: == Fix the build == The build is broken, here's how to fix it: When [this CfC](https://www.w3.org/mid/5B0AEC39-28EC-473D-AA8F-802C7FEF3798@intel.com) passes on 26 March 2024, use the manual publication process. That should fix the build and automated publication workflow. Context: https://github.com/w3c/deviceorientation/pull/142#issuecomment-1993819279 Please view or discuss this issue at https://github.com/w3c/deviceorientation/issues/151 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Wide review has been completed. Thank you all! 🥳 🚀 This wide review round resulted in various positive developments summarized below: - **Accessibility** contributed an entire Accessibility considerations section! - **TAG/Architecture** unearthed an issue related to exposing identifying information about devices; this API got a pass and TAG took an action to work on harmonisation between the TAG guidance on devices and powerful features and what the WebAppSec group has specified in the Permissions spec - **Internationalisation** found no issues - **Privacy** noted a need for frequency caps, and we agreed to address it prior to Proposed Rec transition - **Security** closed with no comments received Please follow the links in the first comment https://github.com/w3c/deviceorientation/issues/130#issue-2093963178 for details. Also, please note publication to TR is currently blocked due to a workflow issue related to joint deliverables. We're working to fix it, meanwhile please refer to the ED for the latest: https://w3c.github.io/deviceorientation/ -- GitHub Notification of comment by anssiko Please view or discuss this issue at https://github.com/w3c/deviceorientation/issues/130#issuecomment-2007251940 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
anssiko closed this issue. See https://github.com/w3c/deviceorientation/issues/130 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@marcoscaceres - https://github.com/w3c/geolocation-api/issues/15#issuecomment-631896781 -- GitHub Notification of comment by Ahmad-S792 Please view or discuss this issue at https://github.com/w3c/geolocation-api/issues/122#issuecomment-2005656841 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@marcoscaceres - https://github.com/w3c/geolocation-api/issues/15#issuecomment-631896781 -- GitHub Notification of comment by Ahmad-S792 Please view or discuss this issue at https://github.com/w3c/geolocation-api/issues/122#issuecomment-2005656841 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@marcoscaceres - https://github.com/w3c/geolocation-api/issues/15#issuecomment-631896781 -- GitHub Notification of comment by Ahmad-S792 Please view or discuss this issue at https://github.com/w3c/geolocation-api/issues/122#issuecomment-2005656841 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@marcoscaceres - https://github.com/w3c/geolocation-api/issues/15#issuecomment-631896781 -- GitHub Notification of comment by Ahmad-S792 Please view or discuss this issue at https://github.com/w3c/geolocation-api/issues/122#issuecomment-2005656841 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
anssiko has just submitted a new pull request for https://github.com/w3c/deviceorientation: == Add Accessibility considerations == This text is authored by APA WG and its APA consensus is recorded in: https://lists.w3.org/Archives/Public/public-apa-admin/2024Mar/0000.html See https://github.com/w3c/deviceorientation/pull/150 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
anssiko has just submitted a new pull request for https://github.com/w3c/deviceorientation: == Add Accessibility considerations == This text is authored by APA WG and its APA consensus is recorded in: https://lists.w3.org/Archives/Public/public-apa-admin/2024Mar/0000.html See https://github.com/w3c/deviceorientation/pull/150 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
anssiko has just submitted a new pull request for https://github.com/w3c/deviceorientation: == Add Accessibility considerations == This text is authored by APA WG and its APA consensus is recorded in: https://lists.w3.org/Archives/Public/public-apa-admin/2024Mar/0000.html See https://github.com/w3c/deviceorientation/pull/150 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
anssiko has just submitted a new pull request for https://github.com/w3c/deviceorientation: == Add Accessibility considerations == This text is authored by APA WG and its APA consensus is recorded in: https://lists.w3.org/Archives/Public/public-apa-admin/2024Mar/0000.html See https://github.com/w3c/deviceorientation/pull/150 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
himorin has just submitted a new pull request for https://github.com/w3c/geolocation-api: == Added webapps as group == Closes nothing The following tasks have been completed: n/a Implementation commitment: n/a /cc @marcoscaceres See https://github.com/w3c/geolocation-api/pull/144 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
himorin has just submitted a new pull request for https://github.com/w3c/geolocation-api: == Added webapps as group == Closes nothing The following tasks have been completed: n/a Implementation commitment: n/a /cc @marcoscaceres See https://github.com/w3c/geolocation-api/pull/144 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
rakuco has just submitted a new pull request for https://github.com/w3c/deviceorientation: == automation: Adapt to Generic Sensor changes to stash provided readings == Just like with w3c/sensor#487, the idea is to make it possible for users to write, for example ```js await test_driver.create_virtual_sensor(...); await test_driver.update_virtual_sensor(...); window.addEventListener('deviceorientation', ...); ``` and receive the readings above even if the connection to the virtual sensor was made only after the addEventListener() call. Previously, users would need to carefully order the calls to addEventListener(), update_virtual_sensor() and possibly even need to add a dummy event listener first to get everything to work correctly. Unfortunately, just as with w3c/sensor#487 this requires quite a few changes, even more so in this specification, which is quite vague when it comes to connecting to sensors and the lifetimes of such connections. Some of that behavior is now specified for the virtual sensors case, so that each Document has a `[[virtualSensorMapping]]` that maps virtual sensor types to "orientation event platform sensor-likes", a concept borrowed from Generic Sensor's automation section. Similarly to that section, the idea is that: - Whenever the user agent needs to connect to the underlying hardware because addEventListener() was called, it first attempts to find a virtual sensor, get/create an orientation event platform sensor-like, adds it to `[[virtualSensorMapping]]` and to the virtual sensor's connected platform sensors set and retrieves any existing readings from the virtual sensor. - When a Document is being unloaded, all platform sensor-likes in `[[virtualSensorMapping]]` are removed from their virtual sensors' connected platform sensors set. - Similarly, when a virtual sensor is removed, any platform sensor-likes in its connected platform set have their associated "device sensor" set to null. In the rest of the spec, we switch from attempting to derive a virtual sensor from the top-level traversable directly to trying to find a suitable platform sensor-like entry in `[[virtualSensorMapping]]` and checking its associated virtual sensor when one is set. Related to: w3c/sensors#478. See https://github.com/w3c/deviceorientation/pull/147 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
rakuco has just submitted a new pull request for https://github.com/w3c/deviceorientation: == automation: Adapt to Generic Sensor changes to stash provided readings == Just like with w3c/sensor#487, the idea is to make it possible for users to write, for example ```js await test_driver.create_virtual_sensor(...); await test_driver.update_virtual_sensor(...); window.addEventListener('deviceorientation', ...); ``` and receive the readings above even if the connection to the virtual sensor was made only after the addEventListener() call. Previously, users would need to carefully order the calls to addEventListener(), update_virtual_sensor() and possibly even need to add a dummy event listener first to get everything to work correctly. Unfortunately, just as with w3c/sensor#487 this requires quite a few changes, even more so in this specification, which is quite vague when it comes to connecting to sensors and the lifetimes of such connections. Some of that behavior is now specified for the virtual sensors case, so that each Document has a `[[virtualSensorMapping]]` that maps virtual sensor types to "orientation event platform sensor-likes", a concept borrowed from Generic Sensor's automation section. Similarly to that section, the idea is that: - Whenever the user agent needs to connect to the underlying hardware because addEventListener() was called, it first attempts to find a virtual sensor, get/create an orientation event platform sensor-like, adds it to `[[virtualSensorMapping]]` and to the virtual sensor's connected platform sensors set and retrieves any existing readings from the virtual sensor. - When a Document is being unloaded, all platform sensor-likes in `[[virtualSensorMapping]]` are removed from their virtual sensors' connected platform sensors set. - Similarly, when a virtual sensor is removed, any platform sensor-likes in its connected platform set have their associated "device sensor" set to null. In the rest of the spec, we switch from attempting to derive a virtual sensor from the top-level traversable directly to trying to find a suitable platform sensor-like entry in `[[virtualSensorMapping]]` and checking its associated virtual sensor when one is set. Related to: w3c/sensors#478. See https://github.com/w3c/deviceorientation/pull/147 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
rakuco has just submitted a new pull request for https://github.com/w3c/deviceorientation: == automation: Adapt to Generic Sensor changes to stash provided readings == Just like with w3c/sensor#487, the idea is to make it possible for users to write, for example ```js await test_driver.create_virtual_sensor(...); await test_driver.update_virtual_sensor(...); window.addEventListener('deviceorientation', ...); ``` and receive the readings above even if the connection to the virtual sensor was made only after the addEventListener() call. Previously, users would need to carefully order the calls to addEventListener(), update_virtual_sensor() and possibly even need to add a dummy event listener first to get everything to work correctly. Unfortunately, just as with w3c/sensor#487 this requires quite a few changes, even more so in this specification, which is quite vague when it comes to connecting to sensors and the lifetimes of such connections. Some of that behavior is now specified for the virtual sensors case, so that each Document has a `[[virtualSensorMapping]]` that maps virtual sensor types to "orientation event platform sensor-likes", a concept borrowed from Generic Sensor's automation section. Similarly to that section, the idea is that: - Whenever the user agent needs to connect to the underlying hardware because addEventListener() was called, it first attempts to find a virtual sensor, get/create an orientation event platform sensor-like, adds it to `[[virtualSensorMapping]]` and to the virtual sensor's connected platform sensors set and retrieves any existing readings from the virtual sensor. - When a Document is being unloaded, all platform sensor-likes in `[[virtualSensorMapping]]` are removed from their virtual sensors' connected platform sensors set. - Similarly, when a virtual sensor is removed, any platform sensor-likes in its connected platform set have their associated "device sensor" set to null. In the rest of the spec, we switch from attempting to derive a virtual sensor from the top-level traversable directly to trying to find a suitable platform sensor-like entry in `[[virtualSensorMapping]]` and checking its associated virtual sensor when one is set. Related to: w3c/sensors#478. See https://github.com/w3c/deviceorientation/pull/147 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
rakuco has just submitted a new pull request for https://github.com/w3c/deviceorientation: == automation: Adapt to Generic Sensor changes to stash provided readings == Just like with w3c/sensor#487, the idea is to make it possible for users to write, for example ```js await test_driver.create_virtual_sensor(...); await test_driver.update_virtual_sensor(...); window.addEventListener('deviceorientation', ...); ``` and receive the readings above even if the connection to the virtual sensor was made only after the addEventListener() call. Previously, users would need to carefully order the calls to addEventListener(), update_virtual_sensor() and possibly even need to add a dummy event listener first to get everything to work correctly. Unfortunately, just as with w3c/sensor#487 this requires quite a few changes, even more so in this specification, which is quite vague when it comes to connecting to sensors and the lifetimes of such connections. Some of that behavior is now specified for the virtual sensors case, so that each Document has a `[[virtualSensorMapping]]` that maps virtual sensor types to "orientation event platform sensor-likes", a concept borrowed from Generic Sensor's automation section. Similarly to that section, the idea is that: - Whenever the user agent needs to connect to the underlying hardware because addEventListener() was called, it first attempts to find a virtual sensor, get/create an orientation event platform sensor-like, adds it to `[[virtualSensorMapping]]` and to the virtual sensor's connected platform sensors set and retrieves any existing readings from the virtual sensor. - When a Document is being unloaded, all platform sensor-likes in `[[virtualSensorMapping]]` are removed from their virtual sensors' connected platform sensors set. - Similarly, when a virtual sensor is removed, any platform sensor-likes in its connected platform set have their associated "device sensor" set to null. In the rest of the spec, we switch from attempting to derive a virtual sensor from the top-level traversable directly to trying to find a suitable platform sensor-like entry in `[[virtualSensorMapping]]` and checking its associated virtual sensor when one is set. Related to: w3c/sensors#478. See https://github.com/w3c/deviceorientation/pull/147 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
rakuco has just submitted a new pull request for https://github.com/w3c/deviceorientation: == automation: Adapt to Generic Sensor changes to stash provided readings == Just like with w3c/sensor#487, the idea is to make it possible for users to write, for example ```js await test_driver.create_virtual_sensor(...); await test_driver.update_virtual_sensor(...); window.addEventListener('deviceorientation', ...); ``` and receive the readings above even if the connection to the virtual sensor was made only after the addEventListener() call. Previously, users would need to carefully order the calls to addEventListener(), update_virtual_sensor() and possibly even need to add a dummy event listener first to get everything to work correctly. Unfortunately, just as with w3c/sensor#487 this requires quite a few changes, even more so in this specification, which is quite vague when it comes to connecting to sensors and the lifetimes of such connections. Some of that behavior is now specified for the virtual sensors case, so that each Document has a `[[virtualSensorMapping]]` that maps virtual sensor types to "orientation event platform sensor-likes", a concept borrowed from Generic Sensor's automation section. Similarly to that section, the idea is that: - Whenever the user agent needs to connect to the underlying hardware because addEventListener() was called, it first attempts to find a virtual sensor, get/create an orientation event platform sensor-like, adds it to `[[virtualSensorMapping]]` and to the virtual sensor's connected platform sensors set and retrieves any existing readings from the virtual sensor. - When a Document is being unloaded, all platform sensor-likes in `[[virtualSensorMapping]]` are removed from their virtual sensors' connected platform sensors set. - Similarly, when a virtual sensor is removed, any platform sensor-likes in its connected platform set have their associated "device sensor" set to null. In the rest of the spec, we switch from attempting to derive a virtual sensor from the top-level traversable directly to trying to find a suitable platform sensor-like entry in `[[virtualSensorMapping]]` and checking its associated virtual sensor when one is set. Related to: w3c/sensors#478. See https://github.com/w3c/deviceorientation/pull/147 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
rakuco has just submitted a new pull request for https://github.com/w3c/deviceorientation: == automation: Adapt to Generic Sensor changes to stash provided readings == Just like with w3c/sensor#487, the idea is to make it possible for users to write, for example ```js await test_driver.create_virtual_sensor(...); await test_driver.update_virtual_sensor(...); window.addEventListener('deviceorientation', ...); ``` and receive the readings above even if the connection to the virtual sensor was made only after the addEventListener() call. Previously, users would need to carefully order the calls to addEventListener(), update_virtual_sensor() and possibly even need to add a dummy event listener first to get everything to work correctly. Unfortunately, just as with w3c/sensor#487 this requires quite a few changes, even more so in this specification, which is quite vague when it comes to connecting to sensors and the lifetimes of such connections. Some of that behavior is now specified for the virtual sensors case, so that each Document has a `[[virtualSensorMapping]]` that maps virtual sensor types to "orientation event platform sensor-likes", a concept borrowed from Generic Sensor's automation section. Similarly to that section, the idea is that: - Whenever the user agent needs to connect to the underlying hardware because addEventListener() was called, it first attempts to find a virtual sensor, get/create an orientation event platform sensor-like, adds it to `[[virtualSensorMapping]]` and to the virtual sensor's connected platform sensors set and retrieves any existing readings from the virtual sensor. - When a Document is being unloaded, all platform sensor-likes in `[[virtualSensorMapping]]` are removed from their virtual sensors' connected platform sensors set. - Similarly, when a virtual sensor is removed, any platform sensor-likes in its connected platform set have their associated "device sensor" set to null. In the rest of the spec, we switch from attempting to derive a virtual sensor from the top-level traversable directly to trying to find a suitable platform sensor-like entry in `[[virtualSensorMapping]]` and checking its associated virtual sensor when one is set. Related to: w3c/sensors#478. See https://github.com/w3c/deviceorientation/pull/147 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
marcoscaceres has just submitted a new pull request for https://github.com/w3c/deviceorientation: == chore: add Marcos to editorial team == Would like to join the Editorial team, as I'd like to make sure things align with WebKit. See https://github.com/w3c/deviceorientation/pull/146 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
marcoscaceres has just submitted a new pull request for https://github.com/w3c/geolocation-api: == chore: bring Marcos out of retirement == None See https://github.com/w3c/geolocation-api/pull/143 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
reillyeon has just created a new issue for https://github.com/w3c/deviceorientation: == "Status of this document" section needs to reflect join deliverable status == As discussed in https://github.com/w3c/deviceorientation/pull/142 the "Status of this document" section does not sufficiently reflect the joint deliverable status of this specification. That CL adds "text macro" declarations which should be sufficient but there appear to be deficiencies in the Bikeshed boilerplate text which need to be addressed. In particular, the line "This document was produced by the [Devices and Sensors Working Group](https://www.w3.org/groups/wg/das/)." should read something like "This document was produced as a joint deliverable of the [Devices and Sensors Working Group](https://www.w3.org/groups/wg/das/) and [Web Applications Working Group](https://www.w3.org/groups/wg/webapps/)." We also found that while there is a section on the W3C Patent Policy which acknowledges the joint deliverable status it would also be helpful for the document to also be explicit about the need to satisfy the success criteria for both groups. Please view or discuss this issue at https://github.com/w3c/deviceorientation/issues/145 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
reillyeon has just created a new issue for https://github.com/w3c/deviceorientation: == "Status of this document" section needs to reflect join deliverable status == As discussed in https://github.com/w3c/deviceorientation/pull/142 the "Status of this document" section does not sufficiently reflect the joint deliverable status of this specification. That CL adds "text macro" declarations which should be sufficient but there appear to be deficiencies in the Bikeshed boilerplate text which need to be addressed. In particular, the line "This document was produced by the [Devices and Sensors Working Group](https://www.w3.org/groups/wg/das/)." should read something like "This document was produced as a joint deliverable of the [Devices and Sensors Working Group](https://www.w3.org/groups/wg/das/) and [Web Applications Working Group](https://www.w3.org/groups/wg/webapps/)." We also found that while there is a section on the W3C Patent Policy which acknowledges the joint deliverable status it would also be helpful for the document to also be explicit about the need to satisfy the success criteria for both groups. Please view or discuss this issue at https://github.com/w3c/deviceorientation/issues/145 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
To be discussed with PING when a solution is identified, latest prior to the Proposed Rec transition. Context: https://github.com/w3cping/privacy-request/issues/128 -- GitHub Notification of comment by anssiko Please view or discuss this issue at https://github.com/w3c/deviceorientation/issues/87#issuecomment-1985287520 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
To be discussed with PING when a solution is identified, latest prior to the Proposed Rec transition. Context: https://github.com/w3cping/privacy-request/issues/128 -- GitHub Notification of comment by anssiko Please view or discuss this issue at https://github.com/w3c/deviceorientation/issues/87#issuecomment-1985287520 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
To be discussed with PING when a solution is identified, latest prior to the Proposed Rec transition. Context: https://github.com/w3cping/privacy-request/issues/128 -- GitHub Notification of comment by anssiko Please view or discuss this issue at https://github.com/w3c/deviceorientation/issues/87#issuecomment-1985287520 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
To be discussed with PING when a solution is identified, latest prior to the Proposed Rec transition. Context: https://github.com/w3cping/privacy-request/issues/128 -- GitHub Notification of comment by anssiko Please view or discuss this issue at https://github.com/w3c/deviceorientation/issues/87#issuecomment-1985287520 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
anssiko has just submitted a new pull request for https://github.com/w3c/deviceorientation: == Add an inline issue for the maximum sampling frequency cap == None See https://github.com/w3c/deviceorientation/pull/144 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
reillyeon has just submitted a new pull request for https://github.com/w3c/deviceorientation: == Create PULL_REQUEST_TEMPLATE.md == Specification pull requests should be either be editorial or have test coverage and multi-implementor consensus. See https://github.com/w3c/deviceorientation/pull/143 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
reillyeon has just submitted a new pull request for https://github.com/w3c/deviceorientation: == Create PULL_REQUEST_TEMPLATE.md == Specification pull requests should be either be editorial or have test coverage and multi-implementor consensus. See https://github.com/w3c/deviceorientation/pull/143 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
reillyeon has just submitted a new pull request for https://github.com/w3c/deviceorientation: == Create PULL_REQUEST_TEMPLATE.md == Specification pull requests should be either be editorial or have test coverage and multi-implementor consensus. See https://github.com/w3c/deviceorientation/pull/143 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
reillyeon has just submitted a new pull request for https://github.com/w3c/deviceorientation: == Create PULL_REQUEST_TEMPLATE.md == Specification pull requests should be either be editorial or have test coverage and multi-implementor consensus. See https://github.com/w3c/deviceorientation/pull/143 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
reillyeon has just submitted a new pull request for https://github.com/w3c/deviceorientation: == Create PULL_REQUEST_TEMPLATE.md == Specification pull requests should be either be editorial or have test coverage and multi-implementor consensus. See https://github.com/w3c/deviceorientation/pull/143 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Oh I see. I don't understand why it was decided to use nested data structures for this. They should just have been flattened (accelerationX, etc.), but that's too late now. -- GitHub Notification of comment by annevk Please view or discuss this issue at https://github.com/w3c/deviceorientation/issues/91#issuecomment-1973544487 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Oh I see. I don't understand why it was decided to use nested data structures for this. They should just have been flattened (accelerationX, etc.), but that's too late now. -- GitHub Notification of comment by annevk Please view or discuss this issue at https://github.com/w3c/deviceorientation/issues/91#issuecomment-1973544487 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Oh I see. I don't understand why it was decided to use nested data structures for this. They should just have been flattened (accelerationX, etc.), but that's too late now. -- GitHub Notification of comment by annevk Please view or discuss this issue at https://github.com/w3c/deviceorientation/issues/91#issuecomment-1973544487 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Oh I see. I don't understand why it was decided to use nested data structures for this. They should just have been flattened (accelerationX, etc.), but that's too late now. -- GitHub Notification of comment by annevk Please view or discuss this issue at https://github.com/w3c/deviceorientation/issues/91#issuecomment-1973544487 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Oh I see. I don't understand why it was decided to use nested data structures for this. They should just have been flattened (accelerationX, etc.), but that's too late now. -- GitHub Notification of comment by annevk Please view or discuss this issue at https://github.com/w3c/deviceorientation/issues/91#issuecomment-1973544487 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Oh I see. I don't understand why it was decided to use nested data structures for this. They should just have been flattened (accelerationX, etc.), but that's too late now. -- GitHub Notification of comment by annevk Please view or discuss this issue at https://github.com/w3c/deviceorientation/issues/91#issuecomment-1973544487 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
anssiko has just submitted a new pull request for https://github.com/w3c/deviceorientation: == Update status of this document == For CR publication purposes. See https://github.com/w3c/deviceorientation/pull/142 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
reillyeon has just submitted a new pull request for https://github.com/w3c/deviceorientation: == Make DeviceMotionEventInit members nullable with null default == This change reverts #55 and defines the default values of the DeviceMotionEventInit as null as I believe was the original intent of the definition before that change. Null DeviceMotionEvent attributes have semantic meaning (they declare that the host does not provide the given sensor) and so script should be able to initialize an event with its attributes set to null. Fixed #91. See https://github.com/w3c/deviceorientation/pull/141 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
reillyeon has just submitted a new pull request for https://github.com/w3c/deviceorientation: == Make DeviceMotionEventInit members nullable with null default == This change reverts #55 and defines the default values of the DeviceMotionEventInit as null as I believe was the original intent of the definition before that change. Null DeviceMotionEvent attributes have semantic meaning (they declare that the host does not provide the given sensor) and so script should be able to initialize an event with its attributes set to null. Fixed #91. See https://github.com/w3c/deviceorientation/pull/141 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
reillyeon has just submitted a new pull request for https://github.com/w3c/deviceorientation: == Make DeviceMotionEventInit members nullable with null default == This change reverts #55 and defines the default values of the DeviceMotionEventInit as null as I believe was the original intent of the definition before that change. Null DeviceMotionEvent attributes have semantic meaning (they declare that the host does not provide the given sensor) and so script should be able to initialize an event with its attributes set to null. Fixed #91. See https://github.com/w3c/deviceorientation/pull/141 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
reillyeon has just submitted a new pull request for https://github.com/w3c/deviceorientation: == Make DeviceMotionEventInit members nullable with null default == This change reverts #55 and defines the default values of the DeviceMotionEventInit as null as I believe was the original intent of the definition before that change. Null DeviceMotionEvent attributes have semantic meaning (they declare that the host does not provide the given sensor) and so script should be able to initialize an event with its attributes set to null. Fixed #91. See https://github.com/w3c/deviceorientation/pull/141 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@marcoscaceres what's the frequency cap in WebKit? Discussed in https://www.w3.org/2024/02/12-dap-minutes.html#t06 -- GitHub Notification of comment by anssiko Please view or discuss this issue at https://github.com/w3c/deviceorientation/issues/87#issuecomment-1963036688 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
@marcoscaceres what's the frequency cap in WebKit? Discussed in https://www.w3.org/2024/02/12-dap-minutes.html#t06 -- GitHub Notification of comment by anssiko Please view or discuss this issue at https://github.com/w3c/deviceorientation/issues/87#issuecomment-1963036688 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Summoning @marcoscaceres Discussed in https://www.w3.org/2024/02/12-dap-minutes.html#t10 -- GitHub Notification of comment by anssiko Please view or discuss this issue at https://github.com/w3c/deviceorientation/issues/137#issuecomment-1963034619 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Summoning @marcoscaceres Discussed in https://www.w3.org/2024/02/12-dap-minutes.html#t10 -- GitHub Notification of comment by anssiko Please view or discuss this issue at https://github.com/w3c/deviceorientation/issues/137#issuecomment-1963034619 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Do we want to try address this by the upcoming CR Snapshot or defer for later? Works both ways. Discussed in https://www.w3.org/2024/02/12-dap-minutes.html#t10 -- GitHub Notification of comment by anssiko Please view or discuss this issue at https://github.com/w3c/deviceorientation/issues/118#issuecomment-1963034094 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Closing per https://www.w3.org/2024/02/12-dap-minutes.html#t03 -- GitHub Notification of comment by anssiko Please view or discuss this issue at https://github.com/w3c/deviceorientation/issues/30#issuecomment-1963032734 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
anssiko closed this issue. See https://github.com/w3c/deviceorientation/issues/30 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
anssiko closed this issue. See https://github.com/w3c/deviceorientation/issues/11 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config