Rewrite the "removing features" section, incorporating "Support Existing Content" from the HTTP Design Principles

Author: jyasskin

index.bs

@@ -307,22 +307,42 @@ it might still be possible; see [[#removing-features]].
 
 Do not assume that a change or removal is impossible without first checking.
 
-<h3 id=removing-features>Remove or change capabilities only once you understand existing usage</h3>
-
-Prioritize compatibility with existing content when removing or changing functionality.
-
-Once a significant amount of content has come to depend on a particular behavior,
-removing or changing that behavior is discouraged.
-Removing or changing features and capabilities is possible,
-but it first requires that the nature and scope of the impact on existing content
-is well understood.
-This might require research into how features are used by existing content.
-
-The obligation to understand existing usage also applies to any features that content relies upon.
+<h3 id=removing-features>Prioritize compatibility when changing or removing features</h3>
+
+Before changing how a feature behaves,
+fully understand how websites are currently using it.
+This might require research,
+for example by adding metrics to a popular user agent
+and/or by [searching the HTTP Archive](https://har.fyi/guides/getting-started/).
+Breaking content is harmful,
+and the benefit of a change has to
+significantly outweigh that harm to be worth doing.
+
+The obligation to understand existing usage
+also applies to non-standardized or unspecified features
+that content relies upon.
 This includes vendor-proprietary features and
-behavior that might be considered implementation bugs.
-Web features are not solely defined in specifications;
-they are also defined by how content uses those features.
+implementation bugs.
+
+Despite this, it is sometimes acceptable
+to break some existing content
+in order to help a large number of the web's users.
+Breakage is more likely to be acceptable if:
+
+* Only a tiny amount of existing content depend on the feature or behavior.
+* Only a tiny number of people see that content.
+* The content only appears in test cases or examples.
+* The content is currently broken in most recent popular user agents.
+* The content is not on the public web,
+  but is instead found on internal sites
+  with a controlled user environment.
+  Beware in this case that internal sites are
+  often invisible to our analysis tools.
+  Getting a single complaint is often a sign
+  of a much larger amount of hidden breakage.
+* The benefit of breaking content is very large.
+  For example, removing old SSL and TLS versions breaks lots of content
+  but prevents even more security breaches.
 
 <h3 id="leave-the-web-better">Leave the web better than you found it</h3>