Skip to content

Commit c8a5914

Browse files
martinthomsonLeaVeroutorgocynthia
authored
Add some discussion on adding removing features (#469)
* Add some discussion on adding removing features * @torgo likes this, so I'm merging it * Cite HTML * Stability is important. Co-authored-by: Lea Verou <lea@verou.me> * Update index.bs Co-authored-by: Martin Thomson <mt@lowentropy.net> * You can change stuff, see next * Update index.bs * spacing * CARE * Positive and affirmative Co-authored-by: Daniel Appelquist <dan@torgo.com> * Update index.bs Co-authored-by: Lea Verou <lea@verou.me> * Update index.bs Co-authored-by: Sangwhan "fish" Moon <sangwhan@iki.fi> * Redundant * Update index.bs Co-authored-by: Martin Thomson <mt@lowentropy.net> * Update index.bs Co-authored-by: Martin Thomson <mt@lowentropy.net> --------- Co-authored-by: Lea Verou <lea@verou.me> Co-authored-by: Daniel Appelquist <dan@torgo.com> Co-authored-by: Sangwhan "fish" Moon <sangwhan@iki.fi>
1 parent 918cef0 commit c8a5914

File tree

1 file changed

+34
-0
lines changed

1 file changed

+34
-0
lines changed

index.bs

Lines changed: 34 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -281,6 +281,40 @@ In these cases, features should be designed such that it is possible for
281281
code to gracefully fail or be polyfilled.
282282
See [[#feature-detect]].
283283

284+
<h3 id=new-features>Add new capabilities with care</h3>
285+
286+
Add new capabilities to the web with consideration of existing functionality and content.
287+
288+
The Web includes many extension points that allow for additions;
289+
see for example [[HTML#extensibility]].
290+
291+
Before adding items, consider integration with existing, similar capabilities.
292+
If this leads to a preferred design approach that cannot be implemented by only adding items,
293+
it might still be possible; see [[#removing-features]].
294+
295+
Do not assume that a change or removal is impossible without first checking.
296+
Before adding items, consider integration with existing, similar capabilities.
297+
If this leads to a preferred design approach that cannot be implemented by only adding items,
298+
it might still be possible; see [[#removing-features]].
299+
Do not assume that a change or removal is impossible without first checking.
300+
301+
<h3 id=removing-features>Remove or change capabilities only once you understand existing usage</h3>
302+
303+
Prioritize compatibility with existing content when removing or changing functionality.
304+
305+
Once a significant amount of content has come to depend on a particular behavior,
306+
removing or changing that behavior is discouraged.
307+
Removing or changing features and capabilities is possible,
308+
but it first requires that the nature and scope of the impact on existing content
309+
is well understood.
310+
This might require research into how features are used by existing content.
311+
312+
The obligation to understand existing usage also applies to any features that content relies upon.
313+
This includes vendor-proprietary features and
314+
behavior that might be considered implementation bugs.
315+
Web features are not solely defined in specifications;
316+
they are also defined by how content uses those features.
317+
284318
<h3 id="leave-the-web-better">Leave the web better than you found it</h3>
285319

286320
As you add new capabilities to the web platform, do so in a way that improves

0 commit comments

Comments
 (0)