whatwg/webidl

Get specs updated to new dictionary defaulting setup

Closed this issue · 25 comments

bzbarsky commented

Followup to #750 that probably needs to wait for plinss/widlparser#39 and speced/bikeshed#1491 to be fixed.

To-be-triaged list of things that might need updating, based on Gecko's IDL that needed to be changed:

marcoscaceres commented

I can help with the WebApps WG specs and Payments WG spec and get them republished.

ReSpec will emit warnings for this too. We might also implement an “auto fix” for this in ReSpec, so at least Editors drafts will produce the right IDL.

bzbarsky commented

@marcoscaceres Thanks! I'll keep triaging the list above as I have time, and trying to get issues filed.

inexorabletash commented

Once bikeshed is ready, I can take the IndexedDB and entries-api ones.

In the above checklist, MediaStreamAudioDestinationNode, OscillatorNode, PannerNode, StereoPannerNode, WaveShaperNode, PeriodicWave should be added to the webaudio batch.

Presumably the UDP* and TCP* ones are Firefox OS residue?

Also, IDBFileHandle is non-standard, it's a Gecko thing. Similarly, there is no standard IDBFactory method that takes a dictionary - that's a nonstandard Gecko extension.

Filed w3c/IndexedDB#285 and WICG/entries-api#31

bzbarsky commented

should be added to the webaudio batch

Done, thanks. Hadn't gotten to those yet. ;)

Presumably the UDP* and TCP* ones are Firefox OS residue?

They started out with Firefox OS, but at this point it looks like Firefox devtools use them (e.g. for adb connection). More pertinently, https://www.w3.org/2012/sysapps/tcp-udp-sockets/ is a thing, but doesn't seem to contain any actual IDL, though https://www.w3.org/TR/tcp-udp-sockets/ does. Not sure whether it's worth trying to get that updated; it seems pretty dead at the moment... I'll take all the TCP* and UDP* bits out of the list for now.

Also, IDBFileHandle is non-standard, it's a Gecko thing

Yep, I just dropped all the IDB things in without checking carefully, since the IDB spec needs some updates... I'll remove it from the list.

Similarly, there is no standard IDBFactory method that takes a dictionary - that's a nonstandard Gecko extension.

Removed from list, thanks.

There are likely more Gecko-specific things in the untriaged list; I removed some obvious ones as a first pass, but as you found there's more there...

Thank you for filing the IDB and entries-api issues!

marcoscaceres commented

Sent w3c/payment-request#874 for Payment Request:

You can ✓:

  • PaymentMethodChangeEvent
  • PaymentRequestUpdateEvent
  • PaymentRequest
  • PaymentResponse
  • MerchantValidationEvent
marcoscaceres commented

Sent w3c/FileAPI#134 for File API, which covers:

  • File
  • Blob
CYBAI commented

Sent w3c/ServiceWorker#1448 for ServiceWorker, which covers:

  • ServiceWorker
  • ServiceWorkerContainer
  • Client
  • Clients
  • ExtendableEvent
  • ExtendableMessageEvent
  • Cache
  • CacheStorage
marcoscaceres commented

Sent w3c/push-api#308 for Push, which covers:

  • PushEvent
  • PushManager
  • PushSubscription
marcoscaceres commented

Sent w3c/clipboard-apis#91 for Clipboard APIs, which covers:

  • ClipboardEvent
marcoscaceres commented

Cc @anssiko... there are a few above from your WGs. Could use your help 🙏

marcoscaceres commented

Sent w3c/IntersectionObserver#374 for IntersectionObserver, which covers:

  • IntersectionObserver
marcoscaceres commented

Sent w3c/uievents#239 for UIEvents, which covers:

  • UIEvent
  • FocusEvent
  • MouseEvent
  • WheelEvent
  • InputEvent
  • KeyboardEvent
  • CompositionEvent
marcoscaceres commented

Note above... InputEvent is defined in UIEvents, not in https://w3c.github.io/input-events/, where it's a partial interface.

marcoscaceres commented

Sent WebAudio/web-midi-api#203 for Web Midi, which covers:

  • MIDIConnectionEvent
  • MIDIMessageEvent
marcoscaceres commented

@yoavweiss a few here from the Perf WG:

  • PerformanceEntryEvent
  • PerformanceObserverEntryList
  • PerformanceObserver

If you let me know the specs, I can send some PRs.

annevk commented

All WHATWG standards have a PR at this point.

anssiko commented

PRs submitted for w3c/deviceorientation#78 and w3c/geolocation#27. DeviceProximityEvent, UserProximityEvent, and DeviceLightEvent are deprecated and superseded by ProximitySensor and AmbientLightSensor that were affected and received a similar PR treatment.

In addition, I created PRs for specs that extend Generic Sensor API, also affected.

Ms2ger commented

Everything except WebGL should be filed now; I also removed the Mozilla-internal APIs.

  • ❤️1
domenic commented

Awesome! How did you feel about this process? In particular, how painful was it, and how does that make us feel about changes like #700, or other more speculative ideas people have thrown around?

annevk commented

My main takeaway is that it'd be great to have all tooling PRs ready as well so we only need to communicate a change to everyone once. So that at the point it's communicated everyone can pick it up straight away.

  • 👍1
Ms2ger commented

It wasn't too bad, I think. @bzbarsky's list was very helpful.

  • 👍1
anssiko commented

Second that, the list was helpful.

Related to tooling, and hopefully not too much OT, do we have a tool to conveniently diff spec IDLs against major browsers' implementations to make communicating (proposed) spec changes not just toward downstream specs but also toward implementations easier?

There's https://github.com/mdittmer/web-apis and https://github.com/tidoust/reffy so parts of the problem have already been solved. @foolip @tidoust?

foolip commented

@anssiko a part of https://github.com/mdittmer/web-apis was indeed directed towards this problem, and @mdittmer did in fact produce lists of discrepancies in various categories. We used these lists to file a lot of bugs tracked by https://crbug.com/674593. You can see a lot have been resolved, so the approach worked!

However, we didn't keep triaging differences over time or build tooling to prevent differences from occurring in the first place.

The biggest hurdle, which isn't a very big one, is having a Web IDL parser able to parse both all spec IDL (webidl2.js) but also all the IDL from Chromium, Gecko and WebKit. https://github.com/mdittmer/webidl2-js (not the same as webidl2.js) was once able to do that, but such a parser has to be continuously maintained to keep up with changes.

So to summarize, such tooling isn't deployed, but it's been done before, and the technical challenges are pretty modest. It's mostly a matter of time investment vs. payoff, and web-platform-tests took priority for us.

@lukebjerring FYI about this history and potential area of work.

  • ❤️1
annevk commented

I'm closing this. There's one or two specs still not updated, but by-and-large this has been embraced and tooling will eventually get the laggards updated as well.