- From: Anssi Kostiainen via GitHub <sysbot+gh@w3.org>
- Date: Wed, 20 Sep 2017 12:13:11 +0000
- To: public-device-apis-log@w3.org
Thanks for your comments! >Is the plan to add a feature control hook later? @RByers, that was my initial plan. That said, we could consider adding the hook on the same pass, there's just one procedural issue that need to be cleared: The [Feature Policy spec](https://wicg.github.io/feature-policy/) is currently in incubation, and having an unstable normative reference might be an issue if we want to advance the Battery Status API to Candidate Recommendation and beyond. @dontcallmedom to confirm whether we could make an exception here. >Do we have any idea of how common it is to have x-origin iframe usage of the Battery API? @mounirlamouri, I'd like to know as well, but I don't have any data. If we care strongly about this, would Chrome be fine with us adding telemetry to figure out how common x-origin iframe usage is? > A->B->A embedding scenario @clelland, I'd expect many other platform features be similarly impacted? If so, I wouldn't be concerned about this case at hand specifically. Couple of questions to @clelland et al.: Feature Policy "v1" shipped in Chrome M62. Does it have all the features implemented we'd need for this spec to integrate with it? Do you have established conventions for spec authors on how to hook into the Feature Policy spec the right way. I'm looking for normative spec language I could borrow similarly to e.g. https://w3c.github.io/webappsec-secure-contexts/#new This helps keep specs consistent. Thanks! -- GitHub Notification of comment by anssiko Please view or discuss this issue at https://github.com/w3c/battery/pull/13#issuecomment-330832624 using your GitHub account
Received on Wednesday, 20 September 2017 12:13:05 UTC