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

PresentationReceiver.connectionList can't be [SameObject] anymore #407

Closed
bzbarsky opened this issue Jan 20, 2017 · 6 comments
Closed

PresentationReceiver.connectionList can't be [SameObject] anymore #407

bzbarsky opened this issue Jan 20, 2017 · 6 comments

Comments

@bzbarsky
Copy link

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

@mfoltzgoogle
Copy link
Contributor

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?

@bzbarsky
Copy link
Author

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.

@mfoltzgoogle
Copy link
Contributor

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.

@bzbarsky
Copy link
Author

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

@mfoltzgoogle
Copy link
Contributor

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

@anssiko
Copy link
Member

anssiko commented Jan 24, 2017

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants