search

w3ctag / design-principles

A small-but-growing set of design principles collected by the TAG while reviewing specifications
https://w3ctag.github.io/design-principles
178 stars 46 forks source link

New principle: Remove deprecated functionality responsibly #361

Open jyasskin opened 2 years ago

jyasskin commented 2 years ago

This came up in some discussion around the draft Privacy Principles. We want to evolve the web toward improved privacy, and we're trying to write down the principles that guide new APIs to do what we want, and the removal of old APIs that don't do what we want. At the same time, we can't break the Web, and shouldn't break websites' valid use cases until we've developed replacement APIs and they've had adequate time to migrate.

I'd like to write down a principle saying that, even if one of the other principles (probably in the Ethical Web Principles, Privacy Principles, or a similar document) changes to advise against some existing API, that folks don't have to worry that browsers are going to break them immediately.

I speculate that this document is the right place to put such a principle since it guides API evolution. I'm happy to draft the text once y'all confirm that or suggest a different place.

sandandsnow commented 2 years ago

This is a tricky issue. Just as we don't want sites out there being security vulnerable, we don't want them to be privacy vulnerable. A bad privacy design or implementation should not be supported just because there are sites that depend on that implementation, irrespective of whether there is an alternative. I understand transitions can't always be quick and they may not be easy, and a smooth way forward is the goal, but I don't want legacy to be an obstacle to better privacy design.

jyasskin commented 2 years ago

I think this principle is compatible with everything you said and also describes what browsers do in practice. For security too: see the deprecation of non-TLS HTTP and the gradual rollout of SecureContext annotations. The point of writing it down is to avoid freak-outs when people think we might diverge from standard practice for some new improvement to the principles.

torgo commented 2 years ago

Hi @jyasskin we are just picking this up right now. Would you be able to draft something?

jyasskin commented 2 years ago

Apparently I won't have time to draft something before going on vacation over the summer. I won't be offended if y'all write something instead, or I can pick this back up in the fall.

torgo commented 5 months ago

We're just revisiting this today and noting that we already have a principle about removing or changing capabilities. Maybe this is enough and we don't need to do anything here and can close this? @jyasskin?