Repository navigation
[Guidelines Proposal] Change consensus requirements #2290
Description
Problem
Current contributor guidelines requires 2 major browser engines to implement a new Web API for its definition to be added to TS DOM types. https://github.com/microsoft/TypeScript-DOM-lib-generator#why-is-my-fancy-api-still-not-available-here
Seeing as Blink possesses >75% of browser engine market share and is by FAR the quickest engine to implement new web standards and standard proposals, this requirement causes unnecessary hassle and possible runtime errors if manually defined types are incorrect.
For example: https://x.com/CodeWShreyans/status/2000710168980377885?s=20
The Web Navigation API was added to the HTML Spec in 2022, shortly followed by Blink's implementation later the same year. Webkit released their implementation 3 days ago, over 3 years after Blink. Gecko still does not support it.
Solution
Add types to TS when a standard is supported by one major browser engine AND published to the official HTML spec. However to encourage safe use, the type can be possibly undefined until implemented by two major browser engines.
For example:
interface Window {
navigation: Navigation | undefined
}
Activity
Bashamega commentedon Dec 16, 2025
Duplicate of #998
CodeWithShreyans commentedon Dec 17, 2025
Adam Naji (@Bashamega) not a duplicate, #998 talks about just one part of the solution, not the proposal itself
saschanaz commentedon Dec 19, 2025
Doing this would improperly guide people to write a bunch of web-incompatible code. The two-implementation requirement serves as a way to achieve a balance between web compatibility and usability.
And also Navigation API is getting a bunch of specification feedback after having multiple implementations as it's very complex and still missed details, so it's kinda a bad example.
(ICYMI, #2276 added Navigation API which you should be able to use via
@types/web.)connorshea commentedon Dec 20, 2025
I fully agree with saschanaz, it would result in websites being broken for users not on Chrome, and that'd be problematic for the web long-term. It's best to allow standards to be implemented across browsers before the types are available in TypeScript.
CodeWithShreyans commentedon Jan 4, 2026
Totally reasonable arguments but my question is should we be measuring compatibility by market share or by number of engines. The fact that every single major browser except Firefox and Safari uses Blink is also important.
So considering either the number of browsers (not engines) or the market share would make more sense IMO.
guillaumebrunerie commentedon Aug 5, 2026
Maybe it would actually make more sense to only add APIs to TypeScript when they reach Baseline Newly available?
I agree that the current "2 engines" is pretty ad-hoc. On the other hand, Baseline is a separate metric that seems to measure exactly what is needed here, namely when does a feature become generally available to use on the web. It is however even more restrictive than the current requirement.
saschanaz commentedon Aug 5, 2026
Yeah, that basically just means 3 engines instead of 2.
2 was somewhere in between so that we can balance between early adopters and web compatibility. 2 also means the other one feels pressure to implement it too, otherwise it will suffer from compatibility issue, meaning there's higher chance that it eventually will become 3 implementers anyway.
saschanaz commentedon Aug 5, 2026
re: many other browsers also use blink
The main reason MDN and others do not list them is because they do not participate in standards discussion nor have implementation independence - they just ship whatever the upstream ships, the only practical choice they have is to turn individual features on or off. (Servo and Ladybird do both but then they have no stable release.)