Wide review tracker

[anssiko]

About

This is a meta issue to track wide review for the DeviceOrientation Event Specification.

An important part of wide review is horizontal review from W3C's key horizontal groups listed below in horizontal groups section. Also feedback from other stakeholders is equally important. Additional pointers are welcome via comments.

Legend:
🔴 Review request not submitted
🟡 Review request submitted
🔵 Review feedback received
🟢 Review closed as completed

History

The reviews may want to know that...

This spec initially reached CR in August 2016 (history) and was retired in 2017 due to the Geolocation WG closure. In 2019 DAS WG adopted this spec and during 2019-2024 made substantial interoperability, test automation, privacy and editorial improvements as outlined in the changes section.

A new CR Snapshot publication in expected in Q1'24 if no unresolvable concerns in this wide review are unearthed. We expect to make this a joint deliverable between the DAS WG and WebApps WG.

Horizontal groups

🟢 ♿ Accessibility

• Work through this questionnaire
  • Accessibility Checklist #131
• request a review via GitHub from APA
  • DeviceOrientation Event Specification 2024-01-29 > 2024-02-29 a11y-request#71
  • Accessibility considerations contribution merged: Add Accessibility considerations #150

🟢 📐 Architecture

• Ask the TAG for review; see how to work with the TAG
  • DeviceOrientation Event Specification w3ctag/design-reviews#928
• If you are developing javascript APIs you may also want to ask [email protected], a technical discussion list shared by W3C and ECMA's TC 39
• Confirmed completed DeviceOrientation Event Specification w3ctag/design-reviews#928 (comment)
  • Proposal: No issues related to JS language features that should be brought to TC 39 for consideration.

🟢 🌍 Internationalisation

• Read the Request a review page
• work through the Short Checklist
  • Internationalization Checklist #132
• request a review via GitHub
  • DeviceOrientation Event Specification 2024-01-29 > 2024-02-29 i18n-request#224
  • Confirmed completed DeviceOrientation Event Specification 2024-01-29 > 2024-02-29 i18n-request#224 (comment)

🟢 🔍 Privacy

• Write a "Privacy Considerations" section for your document, taking into account the Self-Review Questionnaire: Security and Privacy, Mitigating Browser Fingerprinting in Web Specifications, and RFC6973
  • Self-Review Questionnaire self-assessment
  • Spec: Security and privacy considerations
• request a review via GitHub from the Privacy Interest Group
  • DeviceOrientation Event Specification 2024-01-29 > 2024-02-29 w3cping/privacy-request#128
  • Confirmed completed DeviceOrientation Event Specification 2024-01-29 > 2024-02-29 w3cping/privacy-request#128 (comment) with PR Add an inline issue for the maximum sampling frequency cap #144
    • Security and Privacy Self-Review Questionnaire Add Security and Privacy Self-Review Questionnaire #126 reviewed by @lknik

🟢 🔒 Security

• Write a "Security Considerations" section for your document, taking into account the Self-Review Questionnaire: Security and Privacy
  • Spec: Security and privacy considerations
• request a review via GitHub
  • DeviceOrientation Event Specification 2024-01-29 > 2024-02-29 security-request#63

Other stakeholders

From who to ask for review:

Horizontal reviews [...] are only a subset of a full wide review, which must also include other stakeholders including Web developers, technology providers and implementers not active in the Working Group, external groups and standards organizations working on related areas, etc.

[anssiko]

@himorin @rakuco @reillyeon if this wide review plan sounds good to you I will start engaging with the horizontal groups seeking your review and input on any materials required.

[anssiko]

The first proposal for the a11y checklist response is available for review and comment in #131. Once the WG is happy we'll submit an a11y review request providing this issue #131 as input.

[reillyeon]

This plan looks good to me. Can we also schedule an ad-hoc WG meeting to triage the currently open issues and tag them with what should or should not be resolved before PR? I think we're looking pretty good but it

[himorin]

The plan also looks good to me.
Although it seems there is no possible at-risk feature from current issue list (most non-vnext are clarification?), we also need to think about possible at-risk...

[anssiko]

Thanks for your support.

The first proposal for the i18n checklist response is also available for review and comment in #132. Proposed summary: Based on this self-assessment the WG believes no Internationalization Considerations section is required. Hearing no concerns, I will approach both a11y and i18n groups to start the discussion.

Privacy, Security and TAG reviews are blocked on PR #126. @rakuco we appreciate your review on that PR. Once we merge that PR I will draft a proposal on how to approach TAG to make the best use of their limited review bandwidth. Security review also depends on that PR, but that review forum has been less active recently, while Privacy and TAG I expect to actively provide feedback.

I support an ad-hoc WG meeting to triage the currently open issues. Let's find a timeslot for that.

[anssiko]

I have now requested Accessibility w3c/a11y-request#71 and Internationalization w3c/i18n-request#224 reviews on behalf of the WG.

[anssiko]

I also initiated Privacy w3cping/privacy-request#128 and Security w3c/security-request#63 reviews with a record of our self-review responses as a reference.

[anssiko]

Hidden in the "[DRAFT] Specification review" disclosure element below is the first proposal for the TAG review request. Please peek inside, everyone.

I want us to iterate on this as a group before we file to make sure we include all relevant information and frame this request properly. Contributions wanted via comments to e.g.:

• Help fill in the blanks
• Additional resources we could provide as a reference
• Any specific questions we want to ask to help focus attention
• Testing story, should we say something about automation?
• Can we better explain the relationship to the Generic Sensor API suite of specs?
• Anything else?

[DRAFT] Specification review

I'm requesting a TAG review of DeviceOrientation Event Specification.

This specification defines several DOM events that provide information about the physical orientation and motion of a hosting device.

• Explainer¹ (minimally containing user needs and example code): This feature has a good MDN entry with example code, see also Motion Sensors Explainer for an introduction to low-level and high-level motion sensors, key concepts
• Specification URL: https://www.w3.org/TR/orientation-event/
• Tests: https://wpt.fyi/results/orientation-event (expected updates)
• User research: [url to public summary/results of research]
• Security and Privacy self-review²: [self-review]
• GitHub repo (if you prefer feedback filed there): https://github.com/w3c/deviceorientation/
• Primary contacts (and their relationship to the specification):
  • Reilly Grant (@reillyeon), Google, editor, co-chair
  • Raphael Kubo da Costa (@rakuco), Intel, editor
  • Anssi Kostiainen (@anssiko), Intel, co-chair
• Organization(s)/project(s) driving the specification: Google, Intel
• Key pieces of existing multi-stakeholder (e.g. developers, implementers, civil society) support, review or discussion of this specification:
  • This specification is implemented by the major browser engines, see MDN browser compatibility and caniuse.com.
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status):

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: A new CR Snapshot expected in March 2024.
• The group where the work on this specification is currently being done: Devices and Sensors WG
  • This specification is expect to become a joint deliverable with the WebApps WG to be jointly published by the two groups before it advances to Rec.
• Major unresolved issues with or opposition to this specification: None
• This work is being funded by: Google, Intel

You should also know that...

This spec initially reached CR in August 2016 (history) and was retired in 2017 due to the Geolocation WG closure. In 2019 DAS WG adopted this spec and during 2019-2024 made substantial interoperability, test automation, privacy and editorial improvements as outlined in the changes section.

These changes since the previous CR Snapshot from 2016 align the specification with widely available implementations, improve interoperability including testability, and add new features for enhanced privacy protections.

This is a high-level API whose low-level API correspondence Orientation Sensor was reviewed by TAG in w3ctag/design-reviews#207 The functional diff is explained in high-level vs. low-level and Orientation Sensor.

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

Click to unfold ⤴️

Thanks for your contributions!

[rakuco]

Thanks @anssiko for all the work so far, and apologies for the time it took for me to comment here.

From a testing perspective, I feel like the tests in WPT need to be improved:

• The existing ones still use MojoJS mocks and aren't very easy to use by non-Chromium implementations. There is ongoing work by @JuhaVainio to convert them to WebDriver; a patch should be submitted for review in the next few days. Not sure if this is a blocker for pinging the TAG though.
• We need new tests for changes that went in since the 2016 CR: requestPermission() and Permissions API integration, integration with the Permissions Policy spec, and rounding of readings to avoid fingerprinting. @JuhaVainio is planning on working on both this quarter. I feel like these are good to have, but not blockers for a new TAG review.

[anssiko]

@rakuco thanks for sharing the rationale for the current test failures and a plan on how to address this. I don't think this blocks the TAG review. TAG may want to understand why we're not fully green, so I updated the TAG review request proposal with a link to this issue. When we publish a CR Snapshot, and if we still show significant red, we are similarly expected to share a rationale and a plan on how to address it. The general policy is that for specs in CR and above we have good test coverage.

[reillyeon]

The bit of the draft TAG review request I'm concerned by is the stakeholder feedback section. I don't know how the TAG wants a feature with existing support by multiple implementations that predates the "standards position" concept to be presented. There are of course years of discussion on this specification from many parties but no clear set of authoritative references to point to. My intuition is to simply state that this specification is implemented by the major browser engines and perhaps to link to MDN or caniuse.com as the source for that assertion.

[anssiko]

We've now completed the i18n review. 🥳

Re TAG review, I updated the draft proposal in #130 (comment) per @reillyeon's suggestion:

Key pieces of existing multi-stakeholder (e.g. developers, implementers, civil society) support, review or discussion of this specification:
This specification is implemented by the major browser engines, see MDN browser compatibility and caniuse.com.

The act of implementing and shipping is the most obvious support signal. This seems appropriate and avoids busywork.

This is the last call for comments to the TAG review request before we submit.

[reillyeon]

It looks good to me. Thank you @anssiko.

[anssiko]

I have submitted the Architecture/TAG design review request: w3ctag/design-reviews#928

With that out of the gate, all the wide review requests are either submitted or completed. I'll bring any review feedback from these reviews to the WG's attention to be addresses in a timely matter.

Related, we'll organize an issue triage working session on 12 Feb 2024. In this working session the editors and other contributors will triage the remaining DeviceOrientation Event Specification open issues in preparation for the expected CR Snapshot publication.

[himorin]

Related, we'll organize an issue triage working session on 12 Feb 2024. In this working session the editors and other contributors will triage the remaining DeviceOrientation Event Specification open issues in preparation for the expected CR Snapshot publication.

will we invite interested WebApps colleagues to this call? (I believe this is one of joint deliverables)

[reillyeon]

I think we should extend the invitation, even if the joint deliverable relationship isn't quite official yet.

[anssiko]

@himorin the easiest path would be to extend the invite to the entire WebApps WG, but Meetings policy suggests we can't do that (yet), right? We can however invite "an individual with a particular expertise to attend a meeting on an exceptional basis".

@marcoscaceres qualifies and can identify other WebApps WG participants for consideration who might be interested in joining the upcoming issue triage working session on 12 Feb 2024.

[himorin]

@himorin the easiest path would be to extend the invite to the entire WebApps WG, but Meetings policy suggests we can't do that (yet), right? We can however invite "an individual with a particular expertise to attend a meeting on an exceptional basis".

I believe it's up to chairs to decide who to be invited, so inviting all participants of WebApp WG individually could work and allowed... In charter we just say The meetings themselves are not open to public participation, however. , but no limitation is set for number of individual invitations.
Also we don't plan to have any call for consensus type discussion during planned call, we don't need to consider of voting right issue. (of course, since Guide for joint deliverables requires individual consensus per each group, we can and need to run CfC within DAS WG independently at some future point.)

[anssiko]

Thanks @himorin, @marcoscaceres has been invited. It might not be the perfect time for him to attend, which I apologize in advance.

To keep this working session productive I prefer to invite only people informed of this specification and its latest developments. Any other individuals interested and brought to our attention will be considered.

[anssiko]

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 #130 (comment) 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/