Either sounds fine to me. Please open something in the bug tracker?
On Fri, May 7, 2010 at 10:12 PM, ben turner bent.mozi...@gmail.com wrote:
I think that switching 'noOverwrite' from false to true is confusing.
I definitely vote to rename the parameter to 'overwrite' and and keep
the
Please note, that like Jonas, I'm not endorsing any of this.
http://dev.w3.org/2009/dap/system-info/
the system which they are running on.
... on which they are running.
Specifically, properties pertaining to the device hardware are addressed.
exposed?
Therefore, a conforming
After considering the various names for constructing an XMLHttpRequest
object that when fetching would not expose the origin and user credentials
I decided to go with AnonXMLHttpRequest(). It was already in the draft as
a boolean argument for the constructor, but feedback from Maciej
Hi timeless,
Thanks for your very valuable comments. I have made the suggested
changes in the document, except for what I add below.
On 10/05/2010 11:12, timeless wrote:
Please note, that like Jonas, I'm not endorsing any of this.
What do you mean by that?
Therefore, a conforming
On Thu, May 6, 2010 at 9:23 PM, ben turner bent.mozi...@gmail.com wrote:
Hi folks,
We've been playing around with the async API and have made some
changes to the IDBRequest interface that we'd like feedback on and
hopefully inclusion in the spec. Here's what we have now:
interface
On Thu, May 6, 2010 at 8:25 PM, ben turner bent.mozi...@gmail.com wrote:
Hey folks,
I'm working with Shawn on the Firefox implementation. Here's our idea
as of now, would you all please comment about things you like or
dislike? Hopefully this follows the gist of the comments shared
already.
On Sat, May 8, 2010 at 1:02 AM, Shawn Wilsher sdwi...@mozilla.com wrote:
Hey all,
Per the current spec [1], noOverwrite defaults to false for put operations
on an object store. Ben Turner and I have been discussing changing the
default of put to not allow overwriting by default. We feel
The consensus on the W3C Extending CSSOM Views matchMedium with
callbacks [1] mailing list was that instead of adding individual DOM
events for changes to media features, we should instead make it
possible to get notified when a user defined media query has changed.
The idea was making it
On Mon, May 10, 2010 at 3:23 PM, Max Froumentin max...@opera.com wrote:
On 10/05/2010 11:12, timeless wrote:
Please note, that like Jonas, I'm not endorsing any of this.
What do you mean by that?
Oh, it's sort of a standard disclaimer that people involved with
Mozilla or as members of other
On Friday 2010-05-07 15:31 -0300, Luiz Agostini wrote:
The consensus on the W3C Extending CSSOM Views matchMedium with
callbacks [1] mailing list was that instead of adding individual DOM
events for changes to media features, we should instead make it
possible to get notified when a user
On 05/05/10 09:05, Robin Berjon wrote:
Hi Manu,
Just a very quick review.
Thanks Robin - preliminary (non-official) feedback below. At a
high-level, all of your points are fair points and will influence the
path forward. Since I sent out the call for reviews, Mark Birbeck has
come up with a
I wonder if it makes sense to have another method for adding the
listener instead of abusing the already existing matchMedium. For
instance, calling matchMedium is going to evaluate the expression,
which is not really necessary.
Kenneth
On Mon, May 10, 2010 at 12:48 PM, L. David Baron
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9698
Summary: Rename all instances of noOverwrite to overwite
Product: WebAppsWG
Version: unspecified
Platform: PC
OS/Version: Windows NT
Status: NEW
Severity: normal
On 5/10/2010 1:33 AM, Jeremy Orlow wrote:
Either sounds fine to me. Please open something in the bug tracker?
Filed bug 9698 [1] on changing noOverwrite to overwrite. I'm going to
wait to file a bug about changing the default until we get more feedback.
Cheers,
Shawn
[1]
On Mon, May 10, 2010 at 4:05 AM, Anne van Kesteren ann...@opera.com wrote:
After considering the various names for constructing an XMLHttpRequest
object that when fetching would not expose the origin and user credentials I
decided to go with AnonXMLHttpRequest(). It was already in the draft as
On May 10, 2010, at 8:48 AM, L. David Baron wrote:
On Friday 2010-05-07 15:31 -0300, Luiz Agostini wrote:
The consensus on the W3C Extending CSSOM Views matchMedium with
callbacks [1] mailing list was that instead of adding individual DOM
events for changes to media features, we should
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 5/7/2010 1:32 PM, Shawn Wilsher wrote:
Hey all,
Per the current spec [1], noOverwrite defaults to false for put
operations on an object store. Ben Turner and I have been
discussing changing the default of put to not allow overwriting by
Hi Simon,
So what you are suggesting is a kind of
document.addMediaRuleListener(mediaquery, listener) etc? I think that
should be quite easy to implement.
Kenneth
On Mon, May 10, 2010 at 2:27 PM, Simon Fraser s...@me.com wrote:
On May 10, 2010, at 8:48 AM, L. David Baron wrote:
On Friday
Ola Joao,
That would mean that the user would have to manually call all
matchMedium queries the user is interested in to find out which one
changed, without us being able to optimize this by not redoing the
parsing of the queries etc.
Att,
Kenneth
On Mon, May 10, 2010 at 2:47 PM, João Eiras
On Monday 2010-05-10 10:27 -0700, Simon Fraser wrote:
This simple callback-based mechanism suffers from various problems (of the
type
that add/removeEventListener were designed to solve):
1. Unclear behavior when calling matchMedium() a second time for the same
query,
with a different
On 5/10/2010 10:36 AM, Kris Zyp wrote:
I believe there are three useful modes:
overwrite: false - Must create a new record
overwrite: true - Must overwrite/update an existing record
(something else) - Create a new record or overwrite/update an existing
(depending on the key of course).
FWIW,
On Mon, 10 May 2010 19:53:52 +0200, Kenneth Christiansen
kenneth.christian...@openbossa.org wrote:
Ola Joao,
That would mean that the user would have to manually call all
matchMedium queries the user is interested in to find out which one
changed, without us being able to optimize this by
Though it will probably become more used due to the media features,
such as (orientation:...), (view-mode:...) etc. especially on mobile
devices.
Anyway, I agree that it is not a bottleneck for the time being.
Kenneth
On Mon, May 10, 2010 at 3:11 PM, João Eiras jo...@opera.com wrote:
On Mon,
On May 10, 2010, at 10:36 AM, Kris Zyp wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 5/7/2010 1:32 PM, Shawn Wilsher wrote:
Hey all,
Per the current spec [1], noOverwrite defaults to false for put
operations on an object store. Ben Turner and I have been
discussing changing the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 5/10/2010 12:53 PM, Maciej Stachowiak wrote:
On May 10, 2010, at 10:36 AM, Kris Zyp wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1
On 5/7/2010 1:32 PM, Shawn Wilsher wrote:
Hey all,
Per the current spec [1], noOverwrite defaults
What is the motivation for such an API which exposes so many details about
the end user? Is there a discussion thread or some document listing the use
cases?
On Wed, May 5, 2010 at 8:54 PM, Robin Berjon ro...@berjon.com wrote:
Hi all,
as part of its work the DAP WG has been developing a
Hi All,
A couple of questions about CORS.
1: Why is CORS an opt-out setup instead of an opt-in?
eg why are all my resource hidden to js by default rather than exposed,
then allowing me to limit access to specific resources at my discretion.
2: Why does CORS prevent this:
function
On Mon, May 10, 2010 at 3:42 PM, Nathan nat...@webr3.org wrote:
Hi All,
A couple of questions about CORS.
1: Why is CORS an opt-out setup instead of an opt-in?
eg why are all my resource hidden to js by default rather than exposed, then
allowing me to limit access to specific resources at
Hi all,
A couple weeks back there was a question as to implementor support for
UMP and CORS, and that ended up launching a longish thread on the
chromium-dev mailing list [1].
Tyler Close has asked me to summarize the conclusions of that thread
here, so ...
1) CORS is already implemented and
Dirk Pranke wrote:
Hi all,
A couple weeks back there was a question as to implementor support for
UMP and CORS, and that ended up launching a longish thread on the
chromium-dev mailing list [1].
Tyler Close has asked me to summarize the conclusions of that thread
here, so ...
1) CORS is
* Nathan wrote:
Personally, I don't follow why JS running in a user agent should have
completely different access rules to the rest of the web, primarily
because a few site admin's feel it's a good idea to expose sensitive
data via IP-based auth on intranets / on the web via stateful sessions
Bjoern Hoehrmann wrote:
* Nathan wrote:
Personally, I don't follow why JS running in a user agent should have
completely different access rules to the rest of the web, primarily
because a few site admin's feel it's a good idea to expose sensitive
data via IP-based auth on intranets / on the
* Nathan wrote:
If you do not depend on a user's special standing with a third party
site, you can configure your server as proxy between your user and the
third party site. That's more difficult for you, but easier for users
and maintainers of third party sites. If we'd do away with the
On Mon, May 10, 2010 at 6:38 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote:
* Nathan wrote:
If you do not depend on a user's special standing with a third party
site, you can configure your server as proxy between your user and the
third party site. That's more difficult for you, but easier for
Jonas Sicking wrote:
On Mon, May 10, 2010 at 6:38 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote:
* Nathan wrote:
If you do not depend on a user's special standing with a third party
site, you can configure your server as proxy between your user and the
third party site. That's more difficult
On 5/10/10 10:21 PM, Nathan wrote:
2: Implement a user UI confirmation screen to allow JS applications xhr
access to other origin resources. (Similar to the allow desktop
notifications scenario in chromium)
Under what conditions would the typical user be able to make an informed
decision
Boris Zbarsky wrote:
On 5/10/10 10:21 PM, Nathan wrote:
2: Implement a user UI confirmation screen to allow JS applications xhr
access to other origin resources. (Similar to the allow desktop
notifications scenario in chromium)
Under what conditions would the typical user be able to make an
On 5/10/10 11:14 PM, Nathan wrote:
2: Implement a user UI confirmation screen to allow JS applications xhr
access to other origin resources. (Similar to the allow desktop
notifications scenario in chromium)
Under what conditions would the typical user be able to make an
informed decision here?
Over the past few years numerous others have hit this issue, for
instance TimBL and his team on the Tabulator project - they had to move
to a browser extension where the access is granted, as have many others,
and as I'll probably end up doing, and those that follow after me.
quote TimBL
On 5/11/10 12:27 AM, Nathan wrote:
This leaves us in a scenario where it is the norm to download, install
and trust an application that runs in the browser
Perhaps. The difference is that it's much harder to do a drive-by app
install.
agree~ish, imho it's more the user giving the Site A
Boris Zbarsky wrote:
On 5/11/10 12:27 AM, Nathan wrote:
This leaves us in a scenario where it is the norm to download, install
and trust an application that runs in the browser
Perhaps. The difference is that it's much harder to do a drive-by app
install.
agree~ish, imho it's more the
41 matches
Mail list logo
