From 642f9267df365fee958e4348b9be609b5a92313e Mon Sep 17 00:00:00 2001 From: Jeffrey Yasskin Date: Thu, 18 Sep 2025 03:04:32 +0000 Subject: [PATCH 01/14] Rewrite the "removing features" section, incorporating "Support Existing Content" from the HTTP Design Principles --- index.bs | 50 +++++++++++++++++++++++++++++++++++--------------- 1 file changed, 35 insertions(+), 15 deletions(-) diff --git a/index.bs b/index.bs index 29be67e4..a0c01c25 100644 --- a/index.bs +++ b/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. -

Remove or change capabilities only once you understand existing usage

- -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. +

Prioritize compatibility when changing or removing features

+ +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.

Leave the web better than you found it

From 72c6e6d5b7d194be196c050c95fa6b3c571f62b5 Mon Sep 17 00:00:00 2001 From: Jeffrey Yasskin Date: Thu, 18 Sep 2025 03:28:35 +0000 Subject: [PATCH 02/14] Fix indentation. --- index.bs | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/index.bs b/index.bs index a0c01c25..e02b964f 100644 --- a/index.bs +++ b/index.bs @@ -334,15 +334,15 @@ Breakage is more likely to be acceptable if: * 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. + 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. + For example, removing old SSL and TLS versions breaks lots of content + but prevents even more security breaches.

Leave the web better than you found it

From ec1d5a80937ee9547ab24d8072b146c0368a8c2e Mon Sep 17 00:00:00 2001 From: Jeffrey Yasskin Date: Wed, 17 Sep 2025 21:12:58 -0700 Subject: [PATCH 03/14] Apply changes from discussion Co-authored-by: Martin Thomson --- index.bs | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/index.bs b/index.bs index e02b964f..be6a04ec 100644 --- a/index.bs +++ b/index.bs @@ -310,10 +310,10 @@ Do not assume that a change or removal is impossible without first checking.

Prioritize compatibility when changing or removing features

Before changing how a feature behaves, -fully understand how websites are currently using it. -This might require research, +understand how websites are currently using it. +Gaining a good understanding 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/). +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. @@ -337,7 +337,7 @@ Breakage is more likely to be acceptable if: 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. + often invisible to analysis tools designed for public content. Getting a single complaint is often a sign of a much larger amount of hidden breakage. * The benefit of breaking content is very large. From bca8b852df896e6786566fc3777f11974674f12a Mon Sep 17 00:00:00 2001 From: Jeffrey Yasskin Date: Wed, 17 Sep 2025 21:16:04 -0700 Subject: [PATCH 04/14] Say who breakage harms. --- index.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.bs b/index.bs index be6a04ec..67de8f88 100644 --- a/index.bs +++ b/index.bs @@ -314,7 +314,7 @@ understand how websites are currently using it. Gaining a good understanding might require research, for example by adding metrics to a popular user agent or by [searching the HTTP Archive](https://har.fyi/guides/getting-started/). -Breaking content is harmful, +Breaking content harms users, and the benefit of a change has to significantly outweigh that harm to be worth doing. From 393f52cd78cd78ecd9b1971814ffcf608fe37ba1 Mon Sep 17 00:00:00 2001 From: Jeffrey Yasskin Date: Thu, 18 Sep 2025 04:22:51 +0000 Subject: [PATCH 05/14] Cite the-web-is-unversioned. --- index.bs | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/index.bs b/index.bs index 67de8f88..98b00cfe 100644 --- a/index.bs +++ b/index.bs @@ -24,6 +24,24 @@ Required IDs: using-http Link Defaults: html (dfn) queue a task/in parallel/reflect +
+{
+  "the-web-is-unversioned": {
+    "authors": [
+      "Sangwhan Moon",
+      "Amy Guy"
+    ],
+    "href": "https://www.w3.org/2001/tag/doc/the-web-is-unversioned/",
+    "title": "The web is unversioned",
+    "status": "TAG Finding",
+    "publisher": "W3C",
+    "date": "27 March 2025",
+    "deliveredBy": [
+      "https://www.w3.org/groups/other/tag/"
+    ]
+  }
+}
+
-
-{
-  "the-web-is-unversioned": {
-    "authors": [
-      "Sangwhan Moon",
-      "Amy Guy"
-    ],
-    "href": "https://www.w3.org/2001/tag/doc/the-web-is-unversioned/",
-    "title": "The web is unversioned",
-    "status": "TAG Finding",
-    "publisher": "W3C",
-    "date": "27 March 2025",
-    "deliveredBy": [
-      "https://www.w3.org/groups/other/tag/"
-    ]
-  }
-}
-