Open chrisguttandin opened 1 year ago
Agreed. The timing object specification draft has not received any significant updates since it was first proposed back in 2015. Notably, the timingsrc implementation has been developed after this and it implements the timing provider by emitting events for vector change and skew change more or less exactly as you propose.
As such, I regard the timingsrc implementation as the most up-to-date description of timing object api.
Should I try to craft a PR for that change?
That would be great indeed!
That said, I think the draft spec document is in need of a quite extensive cleanup in order to be really useful as a reference :)
That's true. Unfortunately I have no experience with updating ReSpec, WebIDL references and all that.
Unfortunately I have no experience with updating ReSpec, WebIDL references and all that.
Refreshing ReSpec, that I can take care of! I'll prepare a PR. That won't provide the cleanup that would be needed, but should at least ease future potential edits.
Refreshing ReSpec, that I can take care of! I'll prepare a PR.
Done in #34
Since
Object.observe()
has turned out to be a dead end I think the spec needs to be updated to use something else.It's currently used by the
TimingObject
to observe thevector
property of aTimingProvider
. I would like to suggest to use an event on theTimingProvider
instead to communicate vector updates. We could use the samechange
event that's already available on aTimingObject
and add it to theTimingProvider
interface, too. ATimingObject
could then listen for this event instead of observing the vector property.