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

Get specs updated to new dictionary defaulting setup #758

Closed
51 of 56 tasks
bzbarsky opened this issue Jul 5, 2019 · 25 comments
Closed
51 of 56 tasks

Get specs updated to new dictionary defaulting setup #758

bzbarsky opened this issue Jul 5, 2019 · 25 comments

Comments

@bzbarsky
Copy link
Collaborator

bzbarsky commented Jul 5, 2019

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:

@bzbarsky
Copy link
Collaborator Author

bzbarsky commented Jul 5, 2019

@annevk @domenic

@marcoscaceres
Copy link
Member

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
Copy link
Collaborator Author

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

@inexorabletash
Copy link
Member

inexorabletash commented Jul 10, 2019

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
Copy link
Collaborator Author

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
Copy link
Member

marcoscaceres commented Jul 11, 2019

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

You can ✓:

  • PaymentMethodChangeEvent
  • PaymentRequestUpdateEvent
  • PaymentRequest
  • PaymentResponse
  • MerchantValidationEvent

@marcoscaceres
Copy link
Member

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

  • File
  • Blob

@CYBAI
Copy link

CYBAI commented Jul 11, 2019

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

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

@marcoscaceres
Copy link
Member

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

  • PushEvent
  • PushManager
  • PushSubscription

@marcoscaceres
Copy link
Member

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

  • ClipboardEvent

@marcoscaceres
Copy link
Member

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

@marcoscaceres
Copy link
Member

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

  • IntersectionObserver

@marcoscaceres
Copy link
Member

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

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

@marcoscaceres
Copy link
Member

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

@marcoscaceres
Copy link
Member

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

  • MIDIConnectionEvent
  • MIDIMessageEvent

@marcoscaceres
Copy link
Member

@yoavweiss a few here from the Perf WG:

  • PerformanceEntryEvent
  • PerformanceObserverEntryList
  • PerformanceObserver

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

@annevk
Copy link
Member

annevk commented Aug 9, 2019

All WHATWG standards have a PR at this point.

@anssiko
Copy link

anssiko commented Aug 9, 2019

PRs submitted for w3c/deviceorientation#78 and w3c/geolocation-api#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.

reillyeon pushed a commit to w3c/geolocation-api that referenced this issue Aug 9, 2019
This was referenced Aug 21, 2019
@Ms2ger
Copy link
Member

Ms2ger commented Aug 22, 2019

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

@domenic
Copy link
Member

domenic commented Aug 22, 2019

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
Copy link
Member

annevk commented Aug 22, 2019

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.

@Ms2ger
Copy link
Member

Ms2ger commented Aug 23, 2019

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

@anssiko
Copy link

anssiko commented Aug 23, 2019

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
Copy link
Member

foolip commented Aug 26, 2019

@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.

@annevk
Copy link
Member

annevk commented May 23, 2022

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.

@annevk annevk closed this as completed May 23, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

9 participants