See https://www.w3.org/Bugs/Public/show_bug.cgi?id=25048#c10 and heycam/webidl@4c9c298

We've cherrypicked a couple of definitions out of the WEBIDL-2 editor's draft but not sure if that commits our entire spec to align with it. @tidoust what do you think?

webidl-2 is what all specs should be aligning with. "webidl-1" is known-broken in various ways and isn't meant to be used as a reference by anyone, or so I was told by the people who published it.

Well, hopefully webidl-2 is an improvement on webidl-1 (otherwise why are people working on it).

My concern is about relative spec maturity and if we end up with a Presentation API that won't align with whatever webidl-2 becomes.

webidl-1 has no spec maturity (e.g. it has tons of unresolved issues that are never planned to be resolved), so...

In general, if issues come up with Presentation API due to IDL changes, we'll need errata to Presentation API. That's just how things work...

Fine by me then to fix this as suggested, sounds like webidl-2 is better in the long run.

We did publish our most recent CR that references https://heycam.github.io/webidl/ so this won't be an issue for the upcoming CR refresh tracked in #406.

@tidoust I'd like to be proactive, so could you help clear the road ahead to PR and REC with respect to referencing the latest WebIDL spec, so that this does not introduce a blocker when we get there?