Consider wiring up `pkg:js_interop` types into `pkg:web`

[kevmoo]

• JSDate
  • input.valueAsDate - https://www.w3.org/TR/2011/WD-html5-20110405/common-input-element-attributes.html#dom-input-valueasdate
    • Sadly, the idl does NOT reflect this is a Date object. 🤷
    • Ugh. I guess Date is no longer recommended from the W3C - https://www.w3.org/Bugs/Public/show_bug.cgi?id=22824

[kevmoo]

CC @nex3 to track bits you're adding.

[harrshita123]

Hi! I would like to work on this issue.
From my understanding, some top-level WebIDL declarations are currently not fully supported by the generator, which leads to missing or incomplete Dart web bindings. I would like to start by focusing on one declaration type at a time (for example, enums), and add proper generation support along with tests.

Please let me know if this approach sounds good, or if there is a preferred starting point or guidance I should follow.
Thanks!

[harrshita123]

@kevmoo
Hi! I took some time to better understand this issue and I would like to propose a focused approach.

From what I understand, HTMLInputElement.valueAsDate returns a JavaScript Date object in browsers. However, the WebIDL used by the pkg:web generator does not clearly reflect that this member returns a Date. Because the generator relies strictly on WebIDL for type information, it may either skip this member, treat it as a less specific type, or fail to map it correctly to JSDate. This creates a mismatch between actual browser behavior and the generated Dart bindings.

The root of the issue seems to be that Date is somewhat legacy in modern specs and not consistently modeled in WebIDL in a way that the generator can consume cleanly. As a result, the generator likely does not have an explicit mapping from WebIDL Date to Dart’s JSDate, or it does not treat it as a supported built-in JS type.

My proposed approach is to first review how the generator currently handles WebIDL types and specifically check how Date is parsed and mapped. If Date is unsupported or treated generically, I would introduce a clear mapping from WebIDL Date to Dart JSDate, ensuring correct nullability. The goal would be for valueAsDate to be generated with a precise type such as JSDate?, matching real browser behavior.

If necessary, this could be implemented either as a general type-mapping improvement (so all Date usages are handled correctly) or as a minimal targeted fix for this specific case, depending on what best fits the generator’s design.

For testing, I would add or update generator golden tests to confirm that valueAsDate is emitted and typed correctly. If appropriate, I would also include a small web interop test that verifies the returned object behaves as a JSDate. I would additionally scan for other WebIDL members that reference Date to ensure the change does not introduce inconsistencies.

This should be a low-risk change since it aligns the bindings more closely with real browser APIs and improves type accuracy rather than expanding the API surface. If valueAsDate is currently loosely typed, tightening it to JSDate? should be an improvement in correctness.

I am happy to start by auditing the current generator behavior around Date and prepare a small, focused PR based on those findings. Please let me know if this direction sounds good or if there’s a preferred way to handle legacy Date types in pkg:web.

[kevmoo]

Great thoughts @harrshita123 . I'm conflicted on what to do here WRT DateTime.

@srujzs @nex3: thoughts?