Re: [whatwg] Notification's click event should be cancelable
On Fri, Aug 15, 2014 at 2:38 PM, Olli Pettay o...@pettay.fi wrote: in order to prevent whatever default action Notification's click event has (for example focus the tab which initiated the Notification), the click event should be cancelable so that .preventDefault() can be called. Some background https://bugzilla.mozilla.org/show_bug.cgi?id=874050mark=25-26#c25 https://bugzilla.mozilla.org/show_bug.cgi?id=1009190#c0 Given that a single notification can be represented by many Notification objects, what kind of semantics are you expecting? A single listener setting the canceled flag causing any action to not be done? -- http://annevankesteren.nl/
Re: [whatwg] Notification's click event should be cancelable
On 08/24/2014 09:53 AM, Anne van Kesteren wrote: On Fri, Aug 15, 2014 at 2:38 PM, Olli Pettay o...@pettay.fi wrote: in order to prevent whatever default action Notification's click event has (for example focus the tab which initiated the Notification), the click event should be cancelable so that .preventDefault() can be called. Some background https://bugzilla.mozilla.org/show_bug.cgi?id=874050mark=25-26#c25 https://bugzilla.mozilla.org/show_bug.cgi?id=1009190#c0 Given that a single notification can be represented by many Notification objects, what kind of semantics are you expecting? A single listener setting the canceled flag causing any action to not be done? Given the very odd Notification API, where the same user input may end up being represented by several click events in the browser... (I think we need to change that somehow, if possible) ...cancelling any of the events should cancel the default action. -Olli
Re: [whatwg] [Fetch] API changes to make stream depletion clearer/easier
On Aug 23, 2014 2:11 PM, James Graham ja...@hoppipolla.co.uk wrote: On 22/08/14 19:29, Brian Kardell wrote: On Fri, Aug 22, 2014 at 1:52 PM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Aug 22, 2014 at 7:15 PM, Brian Kardell bkard...@gmail.com wrote: I still think that calling it bodyStream actually helps understanding all you need and it's short/portable... response.bodyStream.asJSON() seems to at least give the hint that it is a stream that is consumed without getting too crazy. Well 1), response.json() is short too, much shorter in fact. It is, but there was concern that is was too short to be clear/might actually be confusing before it was further shortened. Making it shorter doesn't help that objection - it doesn't make it clearer, does it? I'm not saying this is best I'm offering a proposal that tries to strike the balance with this fact - that's all there is to my comment. So my opinion is that there are two possible scenarios: 1) The API is consistent and friendly enough that, after an initial period of learning how it works, developers will internalize the semantics. In this case the short names are sufficient to describe the functionality and should be preferred because they increase the signal / noise ratio when reading and writing the code. 2) The API has semantics that are so liable to trip up developers that, without reminder of the behaviour, they will constantly make mistakes. In this case we should be working out how to design a less unfriendly API, not bikeshedding which function naming scheme will make the problem least bad. I am slightly concerned that the amount of discussion around naming here belies a belief that the underlying model is going to cause frustration for developers. Is that the case? Speculation on this is tough and has IMO really stymied standards efforts. The best way to know is to put something we think is a good effort out there for real use and get feedback. We're much better of when we can base decisions on data rather than guesswork. Ideally we could reasonably prolyfill the API surface, but for low level primitives, this is tricky. Is there any way we can, even if under the covers it didn't have quite the same implications? If so, let's try. If not, it seems next best would be to get in in a browser or two ASAP and leave it behind a flag until we can collect some. In not sure how negatively this would affect other things like service workers in terms of delays and frustrations though.
Re: [whatwg] Web Bluetooth API
http://webbluetoothcg.github.io/web-bluetooth/use-cases.html#security_privacy lists some of the risks we want to avoid in implementations. The basic model is that the website tells the UA what kinds of devices it can productively connect to, and then the UA presents the user a dialog from which to pick the particular device(s) to pair with the website. Sites can never ask for global bluetooth access, and for initial versions of the API, at least, we won't let them ask for an entire class of devices at once. (It's possible a specially designed class of devices could get around this by pretending to all be a single device.) There's a risk of websites attacking devices through this API. This is currently mitigated by avoiding access to streaming protocols that require the device to include a parser, and allowing access to the GATT format, which defines key/value pairs. It's still likely that some devices will be vulnerable to GATT messages, and we'll need to keep consulting with various security teams to see whether that risk is acceptable. The third risk, of tracking the user through unique Bluetooth IDs, is described in the current spec. Is that the sort of answer you were looking for? Thanks, Jeffrey On Sat, Aug 23, 2014 at 12:46 AM, Jonas Sicking jo...@sicking.cc wrote: The main question that I have is what is the security model? The security section of the spec is very light. / Jonas On Aug 22, 2014 6:34 PM, Jeffrey Yasskin jyass...@chromium.org wrote: We have a draft API for Bluetooth device access at https://webbluetoothcg.github.io/web-bluetooth/, for which I'm planning to send a Blink Intent to Implement email soon. The spec isn't really up to web standard quality yet: we're planning to refine it as we get feedback from implementation and experimental use. However, we'd still appreciate any feedback this group has on the current draft. Feedback as issues at https://github.com/WebBluetoothCG/web-bluetooth/issues will be easiest to incorporate. Feedback as replies to this email is still welcome. Participation at http://lists.w3.org/Archives/Public/public-web-bluetooth/ is even more welcome. :) Thanks, Jeffrey Yasskin P.S. I'll ping Monday so this doesn't get lost over the weekend, but want to give anyone a chance to comment early if you want.
