Re: [vibration] Add implementation report (#55)

Thanks for the pointer to ewebkit/webkit, @anssiko. I've looked at it carefully.

---

### On the EFL implementation

You're right that the ewebkit/webkit repository has `Source/WebCore/Modules/vibration/` and that `Source/cmake/OptionsEfl.cmake` sets `ENABLE_VIBRATION PUBLIC ON` for the EFL port. That is code, and I don't dispute it.

However, several facts bear on whether it constitutes *implementation experience* in the sense the Council recommendation uses that phrase:

1. **ewebkit/webkit is a snapshot of a discontinued port, last updated 3 July 2017.** It is not a maintained implementation.

2. **Bug 171766** (filed 2017-05-05, RESOLVED FIXED), which removed Vibration from the canonical WebKit tree, gives the rationale verbatim:

   > "Not enabled by any ports / Tests are skipped by all ports / Unmaintained code"

   The ewebkit fork and the canonical WebKit tree had diverged by this point, and the bug describes the state of the canonical tree. That said, the fork has not received updates since July 2017 either, and is not a currently maintained implementation.

3. **No WPT test results for EFL WebKit exist anywhere.** The w3c/test-results/vibration folder contains results from November 2014 for Chrome Beta 40 and Firefox Nightly 36. There are no EFL/Samsung/Tizen results.

4. **The devices are gone.** EFL WebKit targeted Samsung Tizen phones from approximately 2012–2017. Even if the Vibration API shipped on those devices, they are end-of-life hardware running software that has not received updates in nearly a decade. The Council asked the WG to document what experience "the API *currently* has" — the word "currently" matters. A defunct port on discontinued hardware does not represent current implementation experience, any more than a removed Gecko implementation would.

The implementation report accurately reflects the current state: single-engine (Blink/Chromium). If there is verifiable evidence that the EFL Vibration implementation passed WPT tests and shipped in a product still available to users, I would update the report to include it.

---

### On the "misplaced" procedural reason

The w3c/test-results/vibration folder contains raw test-result snapshots from 2014 — `CH39.json`, `FF36.json`, `ZC40.json`, `ZF36.json` — all of which are Chrome and Firefox variants. That format is a data dump, not an implementation report.

An implementation report is a document that addresses W3C Process requirements for advancing to Recommendation: it explains what tests exist, who ran them, what the results were, and what conclusions follow for REC advancement. The Council specifically asked the WG to *document* what implementation experience the API has. That is an authored document, not a JSON snapshot. The spec links to it via `implementationReportURI`.

---

### Request

Closing the PR without merging leaves [vibration#33](https://github.com/w3c/vibration/issues/33) open and the Council's condition unmet, which is a gate item for the charter in [charter-drafts#781](https://github.com/w3c/charter-drafts/issues/781).

If there are review concerns about the *content* of the report, I welcome them as review comments. But closing as "misplaced" on grounds that don't hold forecloses the review the WG needs to do. I'd ask that the PR be reopened — @reillyeon has been pinged as a reviewer.


-- 
GitHub Notification of comment by marcoscaceres
Please view or discuss this issue at https://github.com/w3c/vibration/pull/55#issuecomment-4205989183 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 8 April 2026 11:44:41 UTC