MDN Web Docs
-
|
MDN is highly appreciated source of truth for web standards and I am trying to understand when/how certain standard gets the status "to be avoided" or "deprecated", like Windows/unload-event for example? Is it first aligned among web browsers' vendors or W3C consortium and then updated on MDN or the vice versa? For this particular "unload event" I was interested when it got "to be avoided" status. The only way for me to get that information was stepping through MDN page history on Github, all the way back to March 5th 2021. My questions are:
Better understanding of this process could improve the mitigation planning and avoid surprises when one status update is overseen for example. |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments
-
|
Hi @bsrdjan - thanks a lot for opening the discussion. For deprecated, we have a fairly solid definition documented where we are referring to the Browser Compat Data project's definition where necessary, but this page describes what it means and when we use it on MDN: https://developer.mozilla.org/en-US/docs/MDN/Writing_guidelines/Experimental_deprecated_obsolete To quote a relevant section from BCD, deprecated is
And there are some examples that indicate when we mark technology as such in the BCD project documentation. Regarding "to be avoided" - this is a good question and I'm personally not familiar with seeing any other pages marked in this way (it's quite possible you found the only one). This particular admonition predates git history so it's harder to track the rationale behind using it.
The browser compatibility tables should show the status of a feature, whether it is deprecated, on a standards track, or is experimental.
This is more a case of being notified of something becoming deprecated as "to be avoided" is not something we actively propagate through the docs. There is something that the MDN team built called Updates which might be interesting for you. Otherwise, through browser compatibility data itself. Others are welcome to chime in with other methods to get notified.
Browser vendors usually have their own timelines for sunsetting features and the approaches may vary, but are normally usage-based in order to not break real-world applications. Maybe someone else would like to shed some more info on sunsetting practices per vendor, but I think that's the general idea. I hope that helps! |
Beta Was this translation helpful? Give feedback.
-
|
You got a good answer, but I can add some info about:
Usually a vendor will detect an old feature that makes their lives harder. The old feature might prevent changes, cause performance problems, or cause confusion. That vendor (or some developer for that vendor) might decide to get rid of that functionality even though it is often a very slow and painful process since nobody accepts more than a minimum of web breakage. One step on the way can be to get everyone to agree (informally or in W3C or elsewhere) that it should be removed and that is when documentation start including the "deprecated" word. From there to actual removal can be anything from a month (for totally unused features nobody even knew existed) to many years, to never. Sometimes deprecations are used as a way to prevent new usage so that usage remains low, sometimes as a way to try to inspire less usage when usage is currently too high to actually remove a feature. In Chromium we usually discourage vague deprecations since we have found them ineffective and a cause of warning blindness. I hope that added a bit of information about how things happen. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for both answers, it helped me understand the whole process. I would only add that after the status "deprecated" is set in MDN/BCD, the tools already in place like canIUse, autoprefixer etc., start giving warnings, leaving usually enough time for developers to consider next steps. Perhaps the status of this particular The MDN page is telling "Developers should avoid ..." while the BCD database shows no deprecation: import bcd from "@mdn/browser-compat-data" assert { type: "json" };
// https://caniuse.com/mdn-api_window_unload_event
const status_unload = bcd.api.Window.unload_event.__compat;
console.log(status_unload);
// status: { deprecated: false, experimental: false, standard_track: true } <<< |
Beta Was this translation helpful? Give feedback.
You got a good answer, but I can add some info about:
Usually a vendor will detect an old feature that makes their lives harder. The old feature might prevent changes, cause performance problems, or cause confusion. That vendor (or some developer for that vendor) might decide to get rid of that functionality even though it is often a very slow and painful process since nobody accepts more than a minimum of web breakage.
One step on the way can be to get everyone to agree (informally or in W3C or elsewhere) that it should be removed and that is when documentation start including t…