- From: Marcos Caceres <marcosc@w3.org>
- Date: Fri, 20 Aug 2021 16:56:22 +1000
- To: Yoav Weiss <yoavweiss@google.com>
- Cc: Thomas Steiner <tomac@google.com>, "Christiansen, Kenneth R" <kenneth.r.christiansen@intel.com>, "Kostiainen, Anssi" <anssi.kostiainen@intel.com>, Addy Osmani <addyo@google.com>, "TOREINI, EHSAN" <ehsan.toreini@durham.ac.uk>, Noam Helfman <noamh@microsoft.com>, Tarun Bansal <tbansal@google.com>, W3C Devices and Sensors WG <public-device-apis@w3.org>, Alex Russell <slightlyoff@chromium.org>, "ilya@igvita.com" <ilya@igvita.com>, Pete LePage <petele@google.com>
> On 20 Aug 2021, at 12:11 am, Yoav Weiss <yoavweiss@google.com> wrote: > Again - this is being used in the wild today to create better experiences for bandwidth-constrained users, as well as better analytics. The utility of the solution is not in dispute. We know that anything we put out in the wild will be used by someone to do something useful - that's why we specified NetInfo in the first place and put it out there. But that doesn't change the fact that the API might be bad for *reasons* (e.g., privacy). > "Cutting our losses" would mean to regress the web experience for users under harsh network-conditions and remove those developers' ability to optimize their sites for these scenarios. That's absolutely not the case at all: no one said that Chromium should remove the API. We can just acknowledge that it's a Chrome(mium) API. That's totally ok... standardizing something new (supported by all the browser vendors) that developers can transition to should be the goal. That way, we don't break existing content, and we get a path forward. Put differently: just because we have a Chromium-only API shipping right now doesn't mean we can't come up with something different that other browser vendors can adopt. One doesn't negate the other.
Received on Friday, 20 August 2021 06:56:37 UTC