Merge branch 'master' into add-resize-observer

Author: timocov

.gitignore

@@ -281,6 +281,7 @@ __pycache__/
 generated/
 lib/
 inputfiles/browser.webidl.json
-.vscode
+.vscode/*
+!.vscode/launch.template.json
 package-lock.json
 yarn.lock

README.md

@@ -53,9 +53,9 @@ The common steps to send a pull request are:
 
 ### What are the TypeScript team's heuristics for PRs to the DOM APIs
 
-Changes to this repo can have pretty drastic ecosystem effects, because these types are included by default in TypeScript. 
+Changes to this repo can have pretty drastic ecosystem effects, because these types are included by default in TypeScript.
 Due to this, we tend to be quite conservative with our approach to introducing changes.
-To give you a sense of whether we will accept changes, you can use these heuristics to know up-front if we'll be open to merging. 
+To give you a sense of whether we will accept changes, you can use these heuristics to know up-front if we'll be open to merging.
 
 #### Fixes
 
@@ -71,9 +71,9 @@ To give you a sense of whether we will accept changes, you can use these heurist
 > For example, adding a new spec or subsection via a new or updated IDL file
 
 - Does the new objects or fields show up in [mdn/browser-compat-data](https://github.com/mdn/browser-compat-data)? If not, it's likely too soon.
-- Is the IDL source from WHATWG? 
+- Is the IDL source from WHATWG?
     - Are the additions available in at least two of Firefox, Safari and Chromium?
-- Is the IDL source from W3C? 
+- Is the IDL source from W3C?
     - What stage of the [W3C process](https://en.wikipedia.org/wiki/World_Wide_Web_Consortium#Specification_maturation) is the proposal for these changes: We aim for Proposed recommendation, but can accept Candidate recommendation for stable looking proposals.
     - If it's at Working draft the additions available in all three of Firefox, Safari and Chromium
 - Could any types added at the global scope have naming conflicts?
@@ -103,3 +103,4 @@ To give you a sense of whether we will accept changes, you can use these heurist
 - `overridingTypes.json`: types that are defined in the spec file but has a better or more up-to-date definitions in the json files.
 - `removedTypes.json`: types that are defined in the spec file but should be removed.
 - `comments.json`: comment strings to be embedded in the generated .js files.
+- `deprecatedMessage.json`: the reason why one type is deprecated. The reason why it is a separate file rather than merge in comment.json is mdn/apiDescriptions.json would also possibly be deprecated.