If we really want to be pedantic, then I must point out that they're not W3C standards and likely never will be.
- Battery Status API was on a standards track but the last published version is a Candidate Recommendation from 2016
- Web Bluetooth is just a Community Group Draft. It's not even formally adopted by a Working Group.
Neither is likely to progress to Recommendation status as the W3C - IMHO, wisely - requires to independent implementations before a specification is adopted as a web standard.
If we really want to be pedantic the post your comment refers to never said they were W3C standards. It referred to them as W3C specs which since they are api specifications and published by the W3C is accurate even if they are not standards.
It seems like we're really far down the "arguing semantics" curve at this point.
The practical consideration is: These APIs are only supported by one browser. Other major browsers have announced that they have no intention of supporting them. Therefore, use them with caution. If it's an Electron app and nothing but an Electron app, you're probably good to go. If, OTOH, it's a web page or site, and you don't want to alienate non-Chrome users (which would include all iOS users), then you should make sure you aren't doing anything janky when these APIs aren't available or don't work as advertised.
Looking at the netmarketshare stats for August there are 14 browsers which use the blink engine and have a reported market share. Brave is not on the list since it currently reports itself as Chrome. 2 of those browsers have a market share higher than Firefox, Microsoft Edge and Samsung Internet Browser. Samsung Internet Browser is a mobile only browser which ships on Samsung phones and tablets. Removing those and Chrome the remaining 9 blink based browsers combined still have a higher market share than Firefox.
Fair point. I do tend to forget about Edge and Opera.
I think the general thrust of what I'm trying to say stands, though: The grotty procedural details surrounding W3C standards are something that can be left to the W3C to worry about. For those of us who think C-SPAN is boring, the presence of a particular webpage at a particular location on the W3C's website serves as a really bad proxy for browser support statistics.
If we are going to assume that the term 'Web APIs' doesn't presuppose W3C standard-track documents at a minimum, rather than just "the W3C has a document on this", then I think it's safe to say that we are more interested in being argumentative than in communicating.
- Battery Status API was on a standards track but the last published version is a Candidate Recommendation from 2016
- Web Bluetooth is just a Community Group Draft. It's not even formally adopted by a Working Group.
Neither is likely to progress to Recommendation status as the W3C - IMHO, wisely - requires to independent implementations before a specification is adopted as a web standard.