Re: [web-bluetooth] Don't fire characteristicvaluechanged for Read Responses

@Emill, have you come up with a concrete use case where you need to 
distinguish notifications from read responses? I still think that 
adding a field to an event is something we can easily do even after 
everyone's implemented the spec without it.

Re changing the order of "fire an event" and "resolve promise", ["fire
 an event"](https://dom.spec.whatwg.org/#concept-event-fire) is 
synchronous, while "resolve promise" is first observable at the next 
microtask checkpoint, so writing them in the opposite order in the 
spec would result in the same sequence of user-visible actions (except
 for further promises resolved in the event handlers). We could queue 
a task to fire the event, but that risks things getting further out of
 order, and is different from how most events are fired on the web 
platform.

-- 
GitHub Notification of comment by jyasskin
Please view or discuss this issue at 
https://github.com/WebBluetoothCG/web-bluetooth/issues/274#issuecomment-277305615
 using your GitHub account

Received on Friday, 3 February 2017 17:13:33 UTC