[wg/das] Address TAG review and Council recommendation feedback#784
[wg/das] Address TAG review and Council recommendation feedback#784marcoscaceres wants to merge 2 commits intow3c:gh-pagesfrom
Conversation
|
adding r? to @jyasskin (as co-chair of TAG), to secure proper record that this is the consensus of whole TAG. |
|
Thanks @himorin. The TAG's feedback at w3ctag/design-reviews#1187 was developed collectively — this PR proposes charter text to address it. I agree it's worth having a clear record of TAG consensus on whether the proposed text actually addresses our concerns. I'll put this on the agenda for an upcoming TAG meeting so the group can confirm that collectively. That's the right mechanism: per W3C Process §TAG, each TAG participant holds equal voting power regardless of role, so the TAG as a whole is the right body to confirm this rather than any individual member. |
|
@marcoscaceres thank you for adding agenda item for an upcoming TAG meeting. Discussion and conclusion would be meaningful for discussion forward. @jyasskin @tidoust additional text in success criteria could be useful over all groups (of course, not applicable over every groups, depends on situation/background) not limited to this single WG, and if whole TAG reached agreement and resolved to add these text into success criteria, I believe we shall add them also to the charter template. how about? |
| The Working Group will proactively seek published implementer | ||
| positions from browser engines not currently participating in the | ||
| WG. The Working Group will publish a summary of responses — | ||
| including any non-responses — and use these to inform a decision | ||
| on whether to continue, redesign, or discontinue this work on the | ||
| Recommendation track. The Working Group will document that | ||
| decision publicly. |
There was a problem hiding this comment.
In the TAG review, we wrote
We want to ensure that the other specifications fill clear user needs and are making appropriate tradeoffs between those user needs and any potential abuse of the APIs. In many WGs, we can rely on all 3 browser engines to check this, but since this WG does not currently include participation from all major browser engines, we're more concerned here. Could you add this goal to the charter for each of the specifications in that class?
That's not the same as requesting implementer positions: if the WG documents their use cases in an explainer and gets the security and privacy implications reviewed by those 2 WGs, I could see that satisfying the request without requesting implementer positions.
For APIs like this one that aren't shipped in any engine, I think it does make sense to have the charter say that if the WG hasn't identified valuable use cases by the end of this new charter, it'll drop the spec back to an incubation in a CG. If the WG comes up with a different plan, that could also be fine, but I want to see some description of what would justify pulling a spec back to incubation.
| The Working Group will ensure that each specification clearly | ||
| communicates both its implementation status and its intended trajectory | ||
| along the W3C Recommendation Track. At a minimum, the Status of This | ||
| Document section of each specification will describe the current level | ||
| of implementation support and whether the specification is expected to | ||
| advance toward widely implemented Recommendation status. | ||
| </p> | ||
| <p> | ||
| For specifications with limited or single-engine deployment, the | ||
| specification will clearly signal its role and intended direction — | ||
| for example, whether it is an experimental abstraction, a transitional | ||
| design pointing developers toward a consensus alternative, or work with | ||
| limited deployment serving as documentation. |
There was a problem hiding this comment.
In the TAG review, we wrote:
We would like the WG to find a way to signal the expected support level for each specification. There's some discomfort on the TAG with using the same spec status—Candidate Recommendation—for all of:
- deprecated specs that are being maintained while websites migrate to a consensus replacement;
- features that are stable in one engine but opposed by the others;
- "living" consensus specs that never intend to advance to Recommendation; and
- consensus specs that are intended to advance to Recommendation.
At the same time, we recognize that this is the only status the Process defines for patent protection of these kinds of specifications. At a minimum, each document's support level should be in its SotD section, but ideally the WG would find a way to ensure that developers reading a specification can tell at a glance which kind of document they're reading.
That's not the same as asking each spec's SotD to describe its current implementation status, and I don't think I want to see an implementation report embedded into the SotDs.
I would like to request that the WG categorize each spec into something like the above 4 categories, and document that in the SotD. I suspect that we haven't gotten those categories exactly right, and it'd make sense for the WG to discuss exactly what they want to put in the charter.
- Add SotD signaling commitment to Success Criteria: specs must reflect implementation status and intended trajectory; single-engine specs must clearly signal their role; WG will review limited-support specs annually. Addresses TAG charter concern: w3ctag/design-reviews#1187. - Fix Vibration Expected progress: replace vague "haptics capabilities" text with concrete commitment to publish the Council-recommended plan before AC review, with a visible placeholder URL that must be filled in before AC review opens. Also requires updated implementation report (w3c/vibration#33) to be publicly available before AC review. Coordinates haptics work with WebApps WG. Addresses: w3ctag/design-reviews#1187, w3c#781, w3c#782. - Fix Generic Sensor Expected progress: remove "infrastructure for future sensor APIs" framing; add commitment not to charter new GS-derived deliverables without documenting architectural rationale relative to single-layer alternatives. Personal concern by @marcoscaceres; TAG architecture concern flagged for future design reviews. - Fix Ambient Light and Proximity Sensor Expected progress: replace vague "collect feedback" with commitment to seek published implementer positions, publish summary of responses (including non-responses), and document a trajectory decision publicly. Tracking issues: w3c#780, w3c#781, w3c#782, w3c#783 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
marcoscaceres
force-pushed
the
das-wg-charter-2026
branch
from
e9149d2 to
f56b913
Compare
- Vibration Expected progress: replace "before AC review" language with Jeffrey's suggested council-plan.md link (todo placeholder) - Generic Sensor: remove WG commitment on future GS-derived deliverables and associated HTML comment per Jeffrey's feedback - Success Criteria: remove annual re-review paragraph; too heavy for maintenance-mode specs with stable single-engine implementations
3 participants
This PR applies the charter text suggestions posted in #770 (comment), addressing outstanding TAG review and W3C Council concerns. It is intended to be merged into PR #770 or land alongside it.
Changes
Success Criteria — SotD signaling commitment (addresses TAG charter concern, w3ctag/design-reviews#1187):
Adds three paragraphs committing the WG to: signal implementation status and trajectory in each spec's SotD; clearly label the role of single-engine specs; and review limited-support specs at least annually with publicly documented outcomes. Closes #780.
Vibration — Expected progress (addresses TAG charter concern + Council recommendation):
Replaces the vague "device haptics capabilities" text with a concrete commitment to publish the Council-recommended plan before AC review, with a visible
<i class="todo">placeholder URL that must be filled in before the charter proceeds to AC review. Also requires the updated implementation report (w3c/vibration#33) to be publicly available before AC review opens. Coordinates haptics work with the Web Applications WG. Addresses #781, #782.Generic Sensor — Expected progress:
Removes "infrastructure for future sensor APIs" framing. Adds commitment not to charter new Generic Sensor-derived deliverables without first documenting the architectural rationale relative to single-layer API alternatives. HTML comment in source notes the grounding and TAG context.
Ambient Light Sensor + Proximity Sensor — Expected progress:
Replaces vague "collect feedback and may publish a WD" with: proactively seek published implementer positions from non-participating engines, publish a summary of responses (including non-responses), and document a trajectory decision publicly.
Tracking issues
cc @reillyeon @jyasskin @anssiko @himorin