Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing HTMLMediaElement.setSinkId #205

Open
jezell opened this issue Mar 11, 2024 · 1 comment
Open

Missing HTMLMediaElement.setSinkId #205

jezell opened this issue Mar 11, 2024 · 1 comment

Comments

@jezell
Copy link

jezell commented Mar 11, 2024

https://api.dart.dev/stable/3.2.5/dart-html/MediaElement/setSinkId.html

@srujzs
Copy link
Contributor

srujzs commented Mar 14, 2024

This may be a duplicate of #209. The one difference is that this API is also experimental on top of standard_track, and I'm not entirely sure yet if we want to include APIs that are both.

srujzs added a commit to srujzs/web that referenced this issue May 13, 2024
The current implementation only emits APIs that are on the
standards track and supported in Chrome, Firefox, and Safari.
This leaves out widely used APIs like Trusted Types, so this
change relaxes those requirements. In order to support this
change, a number of changes are included:

- BrowserCompatData is modified to handle some slight
discrepancies in how compatibility data is stored, including
global APIs, namespaces, static members, and event handlers.
- Interfaces and namespaces are generated based on whether they
are standards track and experimental. If they are not generated,
any references to them will be replaced by the equivalent JS
type.
- Likewise, inheritance for interfaces is modified to subtype
the first generated interface in the inheritance hierarchy.
- Dictionaries and typedef-like types are generated based on
whether they are used as they don't have compatibility data. In
order to determine this, whenever we generate a _RawType, we
mark it as used, and recursively generate the types needed.
- For each API within an interface, compat data in that interface
and its superinterfaces are used to determine if an API is
generated.
- In order to support the above changes, intermediate
representations for some members (attributes, fields, constants)
are added. There are other members that might be worth moving to
an IR, but that refactoring can be done in a future CL.

Closes a number of issues:

dart-lang#209
dart-lang#234
dart-lang#216
dart-lang#205
dart-lang#203
dart-lang#192
srujzs added a commit that referenced this issue May 21, 2024
* Only emit APIs that are standards track and not experimental

The current implementation only emits APIs that are on the
standards track and supported in Chrome, Firefox, and Safari.
This leaves out widely used APIs like Trusted Types, so this
change relaxes those requirements. In order to support this
change, a number of changes are included:

- BrowserCompatData is modified to handle some slight
discrepancies in how compatibility data is stored, including
global APIs, namespaces, static members, and event handlers.
- Interfaces and namespaces are generated based on whether they
are standards track and experimental. If they are not generated,
any references to them will be replaced by the equivalent JS
type.
- Likewise, inheritance for interfaces is modified to subtype
the first generated interface in the inheritance hierarchy.
- Dictionaries and typedef-like types are generated based on
whether they are used as they don't have compatibility data. In
order to determine this, whenever we generate a _RawType, we
mark it as used, and recursively generate the types needed.
- For each API within an interface, compat data in that interface
and its superinterfaces are used to determine if an API is
generated.
- In order to support the above changes, intermediate
representations for some members (attributes, fields, constants)
are added. There are other members that might be worth moving to
an IR, but that refactoring can be done in a future CL.

Closes a number of issues:

#209
#234
#216
#205
#203
#192

* Generate APIs based on standards track and not experimental

* Handle some TODOs that came up when addressing #209

- Removes an unnecessary null-check
- Refactors getTypeForUnionCalculation to a shared
_getJSTypeEquivalent function
- Avoids shadowing an instance variable

* Address some lints

* Update CHANGELOG and README

* Add types to the field declaration
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants