Update implementation report #33
Comments
|
That would be great. At the same time, it would be good to discuss what use cases are covered by Gamepad’s haptics and some WebApps members have suggested maybe starting to think about incubating something more modern for haptics. For example: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/HapticsDevice/explainer.md My point being that we have really good/interoperable alternatives and path forward even if this API gets obsoleted. |
anssiko
changed the title
|
The WG should update the implementation report and look beyond https://wpt.fyi/results/vibration e.g. https://caniuse.com/vibration that keeps track of other browsers. The latter suggests there's a second implementation to be found. Contributions welcome from folks who have access to any of those browsers on applicable platforms to help contribute test results. How to evolve this API is an exciting but a separate discussion from implementation report. The group has kept a record of new proposals brought to its attention and we've discussed with folks who have worked on domain-specific capabilities e.g. gamepad specific haptics to understand their requirements. The group's position has been this API is positioned as the lowest common denominator across devices and remains a useful feature for the largest user base, complementary to domain-specific haptics features. With time, it might be that the baseline LCD will move so that we can update this API to consider new features. One of the possible such features under consideration is strength control #17 that might be soon about to reach the level it could be considered. Contributions welcome in this area too from interested folks. |
|
@reillyeon, would you mind updating the title of this issue to "Proposal to obsolete this Recommendation"? 🙏 @anssiko, which second independent implementation would meet the requirement?
Note that you need other engines, not other "browsers". If those are all Chromium variants, then that doesn't count as independent implementations and this is still in violation and should be Obsoleted. Chromium Engine
So, where is the second implementation with actual/significant users? (i.e., something worthy of a W3C Recommendation)? Particularly if the Gecko implementation is just lying, and the other browser engines already made it crystal clear they are not interested in this API in this particular shape?
It would be terribly bad if DAS again started working on anything related to this without participation from other implementers (and somewhat naive to think just adding "strength control" would meet the use cases, requirements, and user expectations of modern haptic hardware). It's also not in Scope of DAS's charter to do haptics: what would this fall under? The charter says that Vibration is only in maintenance mode new features wouldn't be in scope of DAS's charter. |
|
Just also noting the spec on TR hasn't been updated since 18 October 2016. Although I see some updates/fixes to the Editor's draft, but no effort to update the actual Recommendation on TR.
I think this the position I'd like to challenge. The group may feel this way, but it might not be the best position to hold for the W3C as a whole. DAP hasn't met its expectations of maintaining the REC, nor continuing to track the actual implementation status of the specification (it's been 7 years and 7 months since this spec was updated on TR, and still has not received a second implementation... with the other second implementation removing support for it!). DAS hasn't even bothered to create or maintain an Errata (404): Due to all of the above, it seems prudent to Obsolete it and let's start on something newer/better. |
|
This issue should be focused on discussion on implementation report update. It is my responsibility as the chair to remind you that the process-defined https://www.w3.org/2023/Process-20231103/#implementation-experience does not talk about engines. These are the rules we follow and adhere to in W3C Working Groups. The DAS WG will carefully review the implementation experience. It is expected to take time due to diversity of implementations. All implementations are important to the WG. One possible approach to fix this issue would be to refer to https://wpt.fyi/results/vibration but that captures only a subset of implementations. |
|
Right, so that according to the Process, it’s the Team (not the Chair, nor Working Group!) that gets to decide what Implementation experience is. So, I think we should get the Team to review these claims. @plehegar can you help us evaluate the situation here? The claim that this is in any way interoperable seems bogus at best. Should other working groups water down their definition of multiple independent implementations to a single engine like DAS does? |
|
As requested, I filed another issue: #34 |
|
Vibration API on Firefox 126.0, all the automated tests show green. Even if just stubs, for web compatibility reasons, the WG will continue the maintenance of this specification as approved by W3C members on February 21st, 2024. |
|
So it’s ok that an implementation needs to lie? Again, didn’t we establish that the Team needs to make the determination if this has interop per the Process? |
DAS can maintaining it but I still hold the W3C needs to reconsider the Recommendation designation because it doesn't have two interoperable implementations. If DAS is going to maintain it, its designation should change to something else. However, the ask to Obsolete it is also fair. DAS should seriously consider that. |
|
From a Process perspective, the Team doesn't re-evaluate a Recommendation nor its implementation report. Once a decision has been announced, there is a period to appeal but, after that, it is set in stone without possibility of appealing. To revisit the status, you need to apply "Process for Rescinding, Obsoleting, Superseding, Restoring a Recommendation", ie a request to obsolete the specification. In this case, the Vibration API is listed in the DAS charter (section 2.3 maintenance), so the request has to go to the DAS Working Group. It cannot go to the Team (see below however), nor the TAG. You did the right thing to raise the matter to the responsible working group, ie you raised a request to obsolete the Recommendation to the Devices and Sensors Working Group. Now, the Working Group has to make a decision regarding your request within 90 days (August 15 or so since your request was done on May 17). If the Group makes a decision, it may be formally objected. If the Group declines to obsolete, raising a formal objection will allow the Team to investigate and, unless the Team finds consensus, the matter will be referred to a W3C Council. If the Working Group doesn't answer by August 15 or so, you are authorized to request that the Team submit your request directly to the Advisory Committee. |
|
Thanks @plehegar. That clarifies things. I'll wait and see how things go and if the WG is willing to revise the status. |
|
I raise a formal objection to allow the Team to investigate the claim/rationale: The W3C Vibration API is falsely claiming to be implemented by Firefox, as indicated in the implementation report. In reality, Firefox no longer supports the API, in that it doesn't actually vibrate. Furthermore, the specification hasn't received interest from any other implementer in years. Additional reasons for obsoleting the Vibration API include:
|
I can't find instructions for how an implementation report should be produced but I think the problem here is relying on WPT results for an API which can be trivially implemented so as to pass the tests without being functional. By doing this Firefox makes the WPT results look like it supports the API when it doesn't. A human writing an implementation report wouldn't claim that Firefox supports the API but the tests can't tell the difference. Some formal guidance on how groups should produce and maintain implementation reports would be appreciated. @anssiko, I am requesting as a Chair of this group that you, as an Editor of this specification, produce a manually-curated implementation report which better reflects the implementation status of this API. @marcoscaceres, please clarify whether your Formal Objection is limited to this misrepresentation of the implementation status or if you will persist is requesting the Team consider overriding the group's decision to continue work on this deliverable. |
I think it's both:
For 2. the Scope of the Charter is:
So my reading of the DAS's charter's Scope is that haptics/vibrations are not in scope. WebApps WG, on the other hand, has haptics explicitly in Scope:
And lists a potential new deliverable from the WICG specifications section:
So it feels inappropriate the continue any evolution of the Vibration API as in DAS (beyond errata, editorial fixes) as haptics are not in scope of the DAS Working Group. I would instead encourage DAS members (of which most, if not all, are members or WebApps), to come work with Web Apps WG on haptics instead. WebApps has a broader set of members and potential implementers than DAP, so it makes more sense to do the Work in Web Apps (and possibly obsolote Vibration if WebApps defines something better). |
|
@reillyeon I'm happy to provide such a manually-curated implementation report. However, I need to get my hands on various mobile devices to test with. If WG participants have appropriate devices I welcome contributions. I'm interested in devices capable of running these implementations: https://caniuse.com/vibration For now we have updated the specification to point to https://wpt.live/vibration/ and https://wpt.fyi/results/vibration for test suite and implementation report respectively. @marcoscaceres, DAS WG is chartered to maintain the Vibration API. Does that address your concern? |
|
@anssiko wrote:
Before you do that, the WG MUST get clarification from the W3C is Chromium-only implementations (see #33 (comment)) count as independent implementations. Otherwise, you'll be wasting your and time writing a report that doesn't meet the process requirements. I again remind you that, as per "6.3.2. Implementation Experience" it's the Team, not Editor or the WG or Chair, that makes the determination about what counts as an implementation. Please get clarification from @plehegar and @himorin before proceeding with the implementation of report. If they say that Chromium-only implementations count, then I don't have a case for my objection on this matter. To be clear, we are taking about this only being supported on Chromium Engine browsers:
Further, the report need to be clear on (noting things I have emphasized) with the Team (not Editor or the WG or Chair) assuring the following:
In particular, the report should note things like why certain implementations don't work and implementer feedback (and particular, the feature being remove from engines like WebKit).
Depends on what "maintain" means to the WG. If maintain means errata, then that is fine, as it only applies to "error that can be resolved by one or more changes in classes 1-3 of section § 6.2.3 Classes of Changes." That is:
If maintain means working on new features, then that remains a concern. In #33 (comment), above @anssiko said:
That seems to imply (and explicitly encourage) feature development of something that is outside the scope of the working group. If that's the case, my formal objection stands. Hope that helps clarify things. |
|
About the implementation experience: From what I see, QQ Browser uses a variant of WebKit and UC Browser "the unique self-developed U4 engine". Per https://caniuse.com/vibration both QQ Browser and UC Browser support the Vibration API and per https://gs.statcounter.com/browser-market-share/all/china these two are the most popular Chinese browsers with 8.59% and 8.27% market share in China respectively as of May 2024 across all platforms. About the maintenance question: The section on maintenance includes the following language:
By DAS WG convention, we list in this section specifications that have reached the Recommendation maturity stage and revising a Recommendation defined by the W3C Process applies to these deliverables. What comes to the strength control feature #17, I'd like to note there are open-source projects in this space, e.g. Haptic Vibration Pattern Generator that generates complex haptic vibrations via |
Right, but one still needs to check if QQ actually vibrates, and that should be weighed against all the other feedback given of why other implementations pulled support (i.e., the wide review). As the questions from the Process I highlighted in #33 (comment) note, it's not just about how widely deployed it is, but if the W3C should be "Recommending" something that numerous industry players have deemed harmful (i.e., the "are there reports of difficulties or problems with implementation?"). Consider: all browsers do pop-ups (let's say 100%), that doesn't mean popups are a great idea and the W3C should be recommending them. Just because something is deployed doesn't mean it's not being used in a way that could annoy users (i.e., see again what I said about "lying with statics", which you either deliberately or inadvertently continue to do). Randomly quoting big numbers doesn't make for a strong case, because it might just mean that a bunch of users are just getting annoyingly buzzed in China. Also doesn't prove anything about the API actually working - as I proved below (It's not supported in iOS, of course). Particularly for a contentious API like this one, a more persuasive story would be: "N browsers have implemented it and we have confirmed it working, and it's being effectively used in this manner [details here]. Example sites: a, b,... and z."
Right, but did you actually read the section? Unlike Geolocation, for instance, the Vibration spec CANNOT receive candidate connections or candidate additions. This is because it was never "explicitly identified as allowing new features using candidate additions." Thus, you can only make "Markup Changes" or "Editorial Changes".
Although fascinating, I'm not sure why that matters? We are discussing what the Working Group can and cannot do. The objection is still that further development of haptics are not in scope of the working group, because they are not listed as such. And, given the feedback, if the W3C should be "recommending" this API at all. |
|
Checked QQ on iOS. It does not vibrate. The API is not implemented: 
|
You will find these are all Chromium. No one is developing any independent engines. However, if you want to spend your time checking, go for it. |
All of those user agent strings look very much like Chromium fork indeed. |
Thanks for helping out. Considering Blink is a fork of WebKit this is important information for the implementation experience assessment. More information on those engines would be required to make an informed decision. There is an informative Simplified Chinese translation of an earlier version of this API that can be helpful when reaching out. |
|
Blink is independent because it's a hard fork with a decade of deviation and features are being completely independently implemented and maintained regardless of WebKit implementation. Without an open source repository it'll be hard to prove how much those engines are independent. |
🤣 ... seriously @anssiko, this is getting absurd. Please tell me you are joking?
It's really not. You are just misdirecting in an effort to waste the Team's time by citing some random site you found that has a bunch of fake/nonsense "engines" listed. They are just Chromium.
Reaching out to who? @siusin (from the W3C Team, who is in China) already reached out to people and is in China and told you they are Chromium. Just accept you are wrong so we can move on. |
|
I too sincerely disagree with what Anssi is arguing, and I agree that we shouldn't consume too much time this way, but I don't think it's a good idea to blame anyone here. I want to point out that this is not the first time within W3C that people disagreed what is independent implementation and what is not. Do we have a normative document about what engines W3C think are independent so that we can refer to that for this kind of discussion? |
|
@saschanaz asked:
This topic was discussed in w3c/AB-public#120 Inviting @cwilso to this discussion. (Sorry in advance for pulling you into this one, but you seem to be on top of the relevant AB discussion.) |
|
I think we can safely accept the following as facts:
Additional implementations would have to come from an engine not derived from Gecko or WebKit, or an implementation in Gecko or WebKit that was built after the original implementations in those engines were removed. We haven't been presented with any evidence of these scenarios. Let's avoid drawing conclusions based on those facts. All I asked for was a report on what implementations exist and I believe we have gathered sufficient information on that topic for @anssiko to produce it. |
|
Perfect! Thanks @reillyeon 🙏 Though perhaps someone can work with @anssiko that has some experience in this area and can provide some oversight? The number of times I've had to refute the misuse of statics, call out bogus web sites, and call out the fact that no actual testing was done (i.e., check that it actually vibrates) doesn't fill me with confidence. |
|
I will be reviewing the PR for the implementation report. |
|
I want to bring to this discussion the following consideration. Perhaps @cwilso and the AB folks have already discussed this, in which case I'm happy to redirect this to a more appropriate place. This comment was inspired by @saschanaz's important question on what is an independent implementation. Also, hopefully piggy-packing on this issue doesn't offend anyone. This case at hand just happens to make this consideration more concrete. Let's go: For certain hardware-centric features, the majority of the implementation (say, in terms of lines of code, or in terms of complexity) is on the layers below the rendering engine. Think of this stack: application, middleware, libraries, OS drivers, OS kernel, OS HAL, firmware and hardware. To simplify, rendering engine is the application, the topmost layer. This topmost layer can be a thin wrapper from a perspective of a particular hardware feature. On all of these layers we can find independent implementations. However, when working on software only features (things we can test end-to-end without specific hardware), we are used to look for independent implementations on the topmost layer only. After reading the implementation experience definition and the latest AB discussion w3c/AB-public#120 I'm wondering whether the independence of the layers below the topmost layer is a more substantial consideration for hardware-centric features? What if the topmost layer is the same, while all the layers underneath have multiple independent implementations, and we can demonstrate interoperability? What if we flip this: the topmost layer has independent implementations, but the layers below that, that make up the majority of the implementation, are the same? To make the latter case more concrete, an interesting case study is the WebRTC API. For that API, there are multiple independent rendering engine implementations, but all are using the same open-source library underneath that is the largest part of all the end-to-end implementation. This specification is a Recommendation so it has passed the implementation experience test. Does the same hold if we have the same topmost layer, but demonstrate independence on the layers below, including interoperability? I was unable to find a good answer to @saschanaz's question. That started to bug me, so I wanted to share this thought. Perhaps the answer is this will be considered on a case by case basis. Thanks for reading. |
|
Could we please move this discussion elsewhere, as it's off-topic for this thread? @anssiko, let's try to stay focused and avoid any further delays. Comparing .vibrate() to WebRTC doesn't seem appropriate. For browser APIs, we rely on Gecko, Chromium, and WebKit as our reference points. This is why we have initiatives like Interop 2024. The definition of "interop" is clear. If you have questions, referring to the Interop project should provide the answers. @reillyeon, would you like me to draft the report? It seems like progress will just keep getting stalled, and we need to keep things moving forward. @anssiko, I encourage you to review the available resources (e.g., a Google search, asking ChatGTP) to find the information you need rather than waiting on others to do it for you. |
|
Also, go and look at your own working group minutes how many times Mozilla and WebKit get mentioned and questions around what WebKit and Mozilla are doing: https://www.w3.org/2023/09/14-dap-minutes.html#t16 It's pretty clear that DAS, and you, know exactly what "Interop" is. Stop pretending this is suddenly some grand philosophical question you've stumbled across for the AB to ponder, and that "if you squint just right...". It's extremely disingenuous and slimy. |
|
@reillyeon, here you go. Please feel to use as the basis. Implementation Report for the W3C's Vibration APIDate: June 8, 2024 Test suiteThe tests were conducted on 8 June 2024 using the test cases from https://wpt.live/vibration/. The testing devices included a Pixel 7 running Android 14 for Chrome for Android and Firefox for Android, and an iPhone 15 running iOS 17.4.1 for Safari. Manual Tests
Automated Tests
W3C Process questions relating to implementation experiencePlease see implementation experience. Is each feature of the current specification implemented, and how is this demonstrated?
Are there independent interoperable implementations of the current specification?
Are there implementations created by people other than the authors of the specification?
Are implementations publicly deployed?
Is there implementation experience at all levels of the specification’s ecosystem (authoring, consuming, publishing…)?
Are there reports of difficulties or problems with implementation?
|
|
@reillyeon, it would be good to amend with the following misuse cases:
|
|
@marcoscaceres : "Feature detection is frequent in code repositories (see GitHub code search)." The link you've provided contains code that detects then uses the API. This pattern is necessary due to lack of implementation, not because of non-use. Can you provide more meaningful evidence for your statement: "Chrome's use counter for navigator.vibrate() shows usage between 0.06% and 0.08% from 2022-2024, primarily for feature detection." |
This is true. But it's also being used for feature detection. There are examples of usage, but those should be looked at in the context of replicating notifications, replicating a gamepad, or if they would be blocked by interactions started without a gesture. I added Chrome's abuse mitigation details to the report.
Actually, all the case do the feature detection, but do then then try misuse the API (all cases prevented by Chrome):
And so on... basically check any of the sites and they all get blocked from using the API by Chrome. You will see:
There's also things like: has disabled it self from pretending to a notification. And just silly uses:
And straight up abuse cases like:
God... the more one looks, the worst it gets with this thing... |
|
@egirard, do you want to check a couple more? I honestly can't find any in the Google's set that are not problematic or abuse cases. Thankfully Chrome just blocks like 99% of them. |
|
This one is fun too: https://wincard.thecashmint.com/?vibrate=123 It tried to vibrate through a URL parameter when everything load😹... and get blocked. Oh, no, it's on an interval! 🙃
Anyway, I hope this report helps clarify the state of the Vibration API on the open web:
It's truly astounding that this API remains with a "W3C Recommendation" status given all the stuff that I've presented above - and it's shocking, disheartening, and absolutely shameful that, despite overwhelming evidence, some here are seriously advocating that it should retain the "Recommendation" status. |
Thanks for digging deeper. Chrome does do a reasonable job of mitigating / blocking "troublesome" vibration calls. And the usage of this API remains extremely low. |
|
In spite of the prevailing opinion, there remains a meaningful use case for haptics. For example, native apps have access to haptics in ios, macOS, android, and windows. I don't have insight into how actively these APIs are used, but there are many examples of haptic feedback being used effectively in native apps. It would be unfortunate to limit web developers access. |
|
Yes, there are valid use cases. I was just discussing a partner's needs which does use vibration. They established a large business as a web app, and I don't think we should force them away. Also, there is abuse, which has been mitigated and could be addressed further if necessary. While some browsers may choose not to expose the feature I don't personally see the issue with this specification existing in the WG. Marcos, your contributions are so valuable to so many specifications in need of material improvement. When you work on those I'm always grateful. |
@marcoscaceres, can you clarify why you think this is misuse? It is a common pattern in mobile games to use on-screen controls to emulate a gamepad, and haptics are a reasonable part of this. To use the Gamepad API for this would be strange since a mobile device would only provide the haptic portion of the Gamepad API. |
|
@egirard wrote:
Right, but the spec itself doesn't provide those mitigations. That's also my point: if one was to implement the "Recommendation", then users of that use agent would have a bad time on the web. That's one of the many reasons why this shouldn't the a "W3C Recommendation"... recommending it is as is harmful to users and the Web.
Absolutely. The utility of haptics as a UI affordance is not in question. It's the context and how the APIs are exposed and used that is, as well as the current form being "Recommended" by the W3C.
Right, and that's not what's in question in this issue. As I mentioned, revisiting haptics in the appropriate context is in the purview of the Web Apps WG. See Gamepad API, for instance - or Microsoft's proposal How it was done with the Vibration API is what's in question here. |
|
@scheib wrote:
Please understand that I'm not saying there are not.
I don't think so either. What I'm arguing for is that:
So, again, I'm not saying let's not do haptics. I'm saying let's do haptics right, but also let's stop "recommending" Vibration as the solution. It's not fit for purpose and it's rife with abuse.
Unlike WebApps, the DAS Working Group is not charted to work on haptics. It is not in scope of the working group (so DAS can't work on it, unless they recharter). The working group is only chartered to do small/light maintenance on the Vibration spec, not add new features. I'm not suggesting the W3C stop working on haptics. On the contrary, I'm suggesting that the work be done with a larger set of stake holders as part of WebApps or the WICG.
🥹 ... I appreciate that. And I'm well aware that this is a real low point in the relationship between myself and DAS. At the same time, I do want all of us to do better here. All I ask is that we look at the evidence objectively, and, as @egirard did: call me out if I too am not being objective enough and let's dig into the details as appropriate - but please let's put the interest of end users first here. |
Right, again, the validity of the use case is not in question. It is if the API is suitable to meet the use cases, and the implications that every website then has access to the API leading to all the abuse/misuse cases. Please consider that it's possible to, for instance, on certain platforms to overlay a virtual gamepad controller on an application - and I believe it may be possible to do a similar thing on Android. Such solutions would provide a very specific, highly accessible, user controllable, developer customizable, virtual controller with haptics that could be provided by the Gamepad API or existing companion spec. That's an entirely different approach to achieving the "I need a gamepad with haptics" use case, without needing to expose This is very much akin to vibration for notifications: they are offloaded to the OS, giving ultimate control to the end-users if they want to turn those off or not, without as much user annoyance. The approach of having a So again, the question of "what use cases does it enable?" must always be paired with "what abuse cases does it enable?" and does the API enable more abuse/misuse than the use cases? (the answer is clearly "yes - more abuse cases") I hope by now it's pretty clear, by looking at the sites that are using the Vibration API, that:
Would it though? I'm just trying to show that there are multiple ways of solving for these use cases - and that falling back to Without getting into a discussion here, hopefully that shows that there might be different ways of approaching the gamepad-like haptics use case in a manner that is better for users and empowers developers to make great experience, while hopefully mitigating the abuse cases seen with the |
|
Put differently: adding more API surface as per #17 would not be a good approach. It would just further exacerbate an already demonstrably dire situation (extremely high rates of misuse of the API). I think we should look seriously at what people might be legitimately using the API for via Github search, and then see if there's better ways of doing that without all the abuse cases. And we should do that in a forum that includes more stakeholders. |
|
@anssiko, any update on publishing a new implementation report? |
w3ctag/obsoletion#7 raises the concern that the current implementation report shows that Firefox supports the API while Mozilla has in fact removed (see bug 1653318).
The implementation report should be updated and without a second implementation this specification no longer meets the requirements for advancing to a W3C Recommendation and is thus a candidate for transition to an Obsolete Recommendation.
The text was updated successfully, but these errors were encountered: