On Tue, Oct 7, 2014 at 8:33 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Sun, Oct 5, 2014 at 7:41 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Oct 2, 2014 at 10:13 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
So we should make a choice, as to whether we want developers
On Oct 7, 2014 11:32 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Tue, Oct 7, 2014 at 8:33 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Sun, Oct 5, 2014 at 7:41 AM, Anne van Kesteren ann...@annevk.nl
wrote:
On Thu, Oct 2, 2014 at 10:13 PM, Domenic Denicola
On Wed, Oct 8, 2014 at 9:51 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
The question is whether it's not natural to assume that *if the promise
fulfills*, that means they got permission. This allows them to do things
like using Promise.all() to join multiple permission requests together and
On Wed, Oct 8, 2014 at 9:40 AM, Silvia Pfeiffer silviapfeiff...@gmail.com
wrote:
Indeed, a Web Bluetooth API would be a great start!
Also, we are writing standards here, so standardizing the
communication of the data between the devices and UAs would be useful.
Both would probably fall
On Wed, Oct 8, 2014 at 9:51 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
The question is whether it's not natural to assume that *if the promise
fulfills*, that means they got permission. This allows them to do things
like using Promise.all() to join multiple permission requests together and
On Mon, Oct 6, 2014 at 9:06 PM, Jonas Sicking jo...@sicking.cc wrote:
I think we should define that non-persistent notifications disappear
after a timeout. And define that on mobile platforms with
notification centers, that these notifications are *not* added
there, but rather is just
On Tue, Oct 7, 2014 at 7:33 PM, Jonas Sicking jo...@sicking.cc wrote:
I don't know of a use-case for that. And given that I think we should
define that non-persistent notifications go away after a timeout, I
think this is the common scenario.
The reason I think we should use timeouts is that
Understood and thanks for the explanation.
Does this have implications for resource hints? Do we want the ability to
specify ³noreferrer² for prerendered pages? Currently noreferrer only
applies to the a tag.
Thanks,
Peter
From: Ilya Grigorik igrigo...@gmail.com
Date: Tuesday, October 7,
Great thanks Boris!
On 10/7/14, 11:49 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 10/7/14, 11:39 AM, Glenn Maynard wrote:
Firefox has had a ticket open for this for about half a
decade
It's fixed and the fix is shipping in Firefox 33 in a week.
-Boris
On Wed, Oct 8, 2014 at 11:36 AM, Peter Lepeska bizzbys...@gmail.com wrote:
Does this have implications for resource hints? Do we want the ability to
specify “noreferrer” for prerendered pages? Currently noreferrer only
applies to the a tag.
My understanding is that you set a global policy,
Okay. I assumed more granular control would be needed but if not then this
works great.
Thanks,
Peter
From: Ilya Grigorik igrigo...@gmail.com
Date: Wednesday, October 8, 2014 at 11:43 AM
To: Peter Lepeska bizzbys...@gmail.com
Cc: Chris Bentzel cbent...@google.com, WHAT Working Group
On Wed, Oct 8, 2014 at 1:07 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Oct 8, 2014 at 9:51 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
The question is whether it's not natural to assume that *if the promise
fulfills*, that means they got permission. This allows them to do things
On Wed, Oct 8, 2014 at 1:31 AM, Tobie Langel tobie.lan...@gmail.com wrote:
On Wed, Oct 8, 2014 at 9:51 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
The question is whether it's not natural to assume that *if the promise
fulfills*, that means they got permission. This allows them to do things
On Wed, Oct 8, 2014 at 5:59 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Oct 8, 2014 at 1:31 AM, Tobie Langel tobie.lan...@gmail.com
wrote:
On Wed, Oct 8, 2014 at 9:51 AM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
The question is whether it's not natural to assume that *if the
From: Tab Atkins Jr. [mailto:jackalm...@gmail.com]
Again, if this means that the current design for await becomes less
convenient, *we can fix await to work better*. It's not set in stone, it's
not developed yet. This is a thing we can change.
To be clear, this will not be happening.
On Wed, Oct 8, 2014 at 6:07 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
What I find interesting here is the claim that people find try/catch annoying
or distasteful.
I don't think you should need try/catch for a common failure case.
That is all. So yes, agreed with Tobie et al.
From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Behalf Of
Anne van Kesteren
I don't think you should need try/catch for a common failure case.
Ah, this is the crux of our minor-disagreement, I think.
IMO using try/catch for a common failure case is fine, *as long as you
On Wed, Oct 8, 2014 at 9:16 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Oct 8, 2014 at 6:07 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
What I find interesting here is the claim that people find try/catch
annoying or distasteful.
I don't think you should need try/catch
On Wed, Oct 8, 2014 at 7:13 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Tue, Oct 7, 2014 at 7:33 PM, Jonas Sicking jo...@sicking.cc wrote:
I don't know of a use-case for that. And given that I think we should
define that non-persistent notifications go away after a timeout, I
think this
On Wed, Oct 8, 2014 at 7:03 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
You keep ignoring the past turns out we like using async errors for
'soft failures' of this kind, and have done it lots of times, and
nobody seems to complain argument.
A user saying no to notifications is not an error.
On Wed, Oct 8, 2014 at 10:39 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Oct 8, 2014 at 7:03 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
You keep ignoring the past turns out we like using async errors for
'soft failures' of this kind, and have done it lots of times, and
nobody
On 10/08/2014 08:03 PM, Tab Atkins Jr. wrote:
On Wed, Oct 8, 2014 at 9:16 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Oct 8, 2014 at 6:07 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
What I find interesting here is the claim that people find try/catch annoying
or
On Wed, Oct 8, 2014 at 9:16 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Oct 8, 2014 at 6:07 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
What I find interesting here is the claim that people find try/catch
annoying or distasteful.
I don't think you should need try/catch
On Wed, Oct 8, 2014 at 10:39 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Oct 8, 2014 at 7:03 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
You keep ignoring the past turns out we like using async errors for
'soft failures' of this kind, and have done it lots of times, and
nobody
24 matches
Mail list logo
