惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
雷峰网
雷峰网
Recent Announcements
Recent Announcements
月光博客
月光博客
G
Google Developers Blog
腾讯CDC
S
Secure Thoughts
大猫的无限游戏
大猫的无限游戏
T
Tenable Blog
云风的 BLOG
云风的 BLOG
W
WeLiveSecurity
博客园 - 【当耐特】
cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
博客园 - 聂微东
The Cloudflare Blog
阮一峰的网络日志
阮一峰的网络日志
人人都是产品经理
人人都是产品经理
P
Privacy International News Feed
MyScale Blog
MyScale Blog
K
Kaspersky official blog
T
The Blog of Author Tim Ferriss
Attack and Defense Labs
Attack and Defense Labs
Spread Privacy
Spread Privacy
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
aimingoo的专栏
aimingoo的专栏
I
Intezer
Vercel News
Vercel News
小众软件
小众软件
Simon Willison's Weblog
Simon Willison's Weblog
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
N
Netflix TechBlog - Medium
P
Proofpoint News Feed
Latest news
Latest news
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
T
Tor Project blog
S
Security Affairs
P
Proofpoint News Feed
博客园 - 三生石上(FineUI控件)
博客园 - Franky
C
Cyber Attacks, Cyber Crime and Cyber Security
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
美团技术团队
Recent Commits to openclaw:main
Recent Commits to openclaw:main
S
Security @ Cisco Blogs
L
LINUX DO - 热门话题
Know Your Adversary
Know Your Adversary
Project Zero
Project Zero
D
Docker
L
Lohrmann on Cybersecurity
F
Full Disclosure

Recent Commits to design-principles:main

Event names should use the present tense (#592) Disambiguate when to add global event handlers (#612) · w3ctag/design-principles@41fee41 Handle non-fully-active documents (#597) chore: fix bikeshed warning about multiple definitions of the <a> ele… · w3ctag/design-principles@6ec7e11 Guidance on extensibility patterns: main spec revision vs registries … Un-escape ampersands in a URL to avoid a bikeshed bug. · w3ctag/design-principles@031a3de Trim trailing whitespace. Replace asking for users for consent with designing for user intent (… Clarify when details should go on events vs targets (#585) · w3ctag/design-principles@79c2b78 Avoid abbreviations generally (#600) · w3ctag/design-principles@9fc15ba Add principles for task sources (#590) · w3ctag/design-principles@444a329 Update ethical-web-principles links and bibrefs (#601) · w3ctag/design-principles@63b43c9 Clean up link-defaults. · w3ctag/design-principles@993e58e Remove trailing whitespace (#593) · w3ctag/design-principles@98f4a02 Ignore index.html at the root. (#586) Fix example in Keep attributes in sync (#591) · w3ctag/design-principles@afb192e Remove notion of asking for consent to reveal AT use (#589) · w3ctag/design-principles@c35b9cd Reference HTTP WG style guide (#587) · w3ctag/design-principles@81e3ff2 Add 'Choose the Appropriate WebIDL Construct for Data and Behavior' (…
Rewrite the "removing features" section, incorporating "Support Exist… · w3ctag/design-principles@62fc770
jyasskin · 2025-10-29 · via Recent Commits to design-principles:main
Original file line numberDiff line numberDiff line change

@@ -352,22 +352,39 @@ it might still be possible; see [[#removing-features]].

352352
353353

Do not assume that a change or removal is impossible without first checking.

354354
355-

<h3 id=removing-features>Remove or change capabilities only once you understand existing usage</h3>

356-
357-

Prioritize compatibility with existing content when removing or changing functionality.

358-
359-

Once a significant amount of content has come to depend on a particular behavior,

360-

removing or changing that behavior is discouraged.

361-

Removing or changing features and capabilities is possible,

362-

but it first requires that the nature and scope of the impact on existing content

363-

is well understood.

364-

This might require research into how features are used by existing content.

365-
366-

The obligation to understand existing usage also applies to any features that content relies upon.

355+

<h3 id=removing-features>Prioritize compatibility when changing or removing features</h3>

356+
357+

Before changing how a feature behaves,

358+

understand how websites are currently using it.

359+
360+

Gaining a good understanding might require research,

361+

for example by adding metrics to a widely-used user agent

362+

or by [searching the HTTP Archive](https://har.fyi/guides/getting-started/).

363+

Breaking content harms users,

364+

and the benefit of a change has to

365+

significantly outweigh that harm to be worth doing

366+

[[the-web-is-unversioned]].

367+
368+

The obligation to understand existing usage

369+

also applies to non-standardized or unspecified features

370+

that content relies upon.

367371

This includes vendor-proprietary features and

368-

behavior that might be considered implementation bugs.

369-

Web features are not solely defined in specifications;

370-

they are also defined by how content uses those features.

372+

implementation bugs.

373+
374+

Despite this, it is sometimes acceptable

375+

to break some existing content

376+

in order to improve the experience for a large number of web users.

377+

Breakage is more likely to be acceptable if:

378+
379+

* Only a tiny amount of existing content depend on the feature or behavior.

380+

* Only a tiny number of people see that content.

381+

* The content appears only in test cases or examples.

382+

* The content is already broken in some widely-used user agents,

383+

and either they have not received many bug reports about it,

384+

or the change is expected to improve interoperability.

385+

* The benefit of breaking content is very large.

386+

For example, removing old SSL and TLS versions caused a number of sites to become unreachable

387+

but prevents more security breaches.

371388
372389

<h3 id="leave-the-web-better">Leave the web better than you found it</h3>

373390