Sam,
I don't think we should include synchronous access to File data
provided by:
DOMString getDataAsText(in DOMString encoding) raises(FileException);
DOMString getDataAsBase64()
raises(FileException);
DOMString getDataA
Jonas,
On Oct 3, 2008, at 12:55 PM, ext Jonas Sicking wrote:
Anne van Kesteren wrote:
On Thu, 02 Oct 2008 01:24:34 +0200, Jonas Sicking
<[EMAIL PROTECTED]> wrote:
I think it would be good if we more explicitly could define the
two, with cookies vs. without cookies, security modes for Acce
On Tue, 30 Sep 2008 00:36:10 +0200, Jonas Sicking <[EMAIL PROTECTED]> wrote:
Jonas Sicking wrote:
Yes, I think it would be helpful to add that information. It wasn't
clear that the credentials flag wasn't part of the key until you put it
this way (though the spec already clearly says so, ju
On Mon, 06 Oct 2008 20:06:24 +0200, Maciej Stachowiak <[EMAIL PROTECTED]>
wrote:
I will ask the ECMAScript committee what the plans are. I think we could
just invent our own ByteArray or BinaryData interface, it would work
better integrated into the language, but ImageData as a custom type
Anne van Kesteren wrote:
On Fri, 03 Oct 2008 14:10:43 +0200, Anne van Kesteren <[EMAIL PROTECTED]>
wrote:
Since Jonas didn't e-mail about this I thought I would. Say
http://x.example/x does a request to http://y.example/y.
http://y.example/y redirects to http://x.example/y. If this request
On Oct 6, 2008, at 5:52 AM, Anne van Kesteren wrote:
I'm considering dropping ByteArray support. That is, removing
support for it from send() and removing responseBody for now. At
this point it's not really clear what the future of ByteArray is and
it seems nobody is driving that work o
Cons:
* Might complicate re-introduction of or equivalent. As
the headers could say allow while the body says not allow.
We already have much of that problem. We can't have the situation
where an AC1 implementation (which doesn't look at the body) grant
access, whereas an AC2 implementation w
Anne van Kesteren wrote:
I'm considering dropping ByteArray support. That is, removing support
for it from send() and removing responseBody for now. At this point it's
not really clear what the future of ByteArray is and it seems nobody is
driving that work or implementing this feature from
Pros:
* Doing the same for HEAD and GET is saner than requiring a preflight for
HEAD.
* Makes cross-site HEAD easier.
Cons:
* Might complicate re-introduction of or equivalent. As
the headers could say allow while the body says not allow.
Given that it's probably worth allowing HEAD
On Fri, 03 Oct 2008 14:10:43 +0200, Anne van Kesteren <[EMAIL PROTECTED]>
wrote:
Since Jonas didn't e-mail about this I thought I would. Say
http://x.example/x does a request to http://y.example/y.
http://y.example/y redirects to http://x.example/y. If this request were
to use the Access
On Mon, 29 Sep 2008 19:47:49 +0200, Jonas Sicking <[EMAIL PROTECTED]> wrote:
What says that an origin is not a URI? Sure, many URIs deny access,
but it looks to me like they are still subsets of URIs. If we say that
they are not URIs, why not go all out and invent a new syntax, such as
http.org
I'm considering dropping ByteArray support. That is, removing support for
it from send() and removing responseBody for now. At this point it's not
really clear what the future of ByteArray is and it seems nobody is
driving that work or implementing this feature from XMLHttpRequest Level 2.
Somehow I missed that it actually happened, but a few days ago the WebApps
WG pushed out another draft of XMLHttpRequest Level 2:
http://www.w3.org/TR/2008/WD-XMLHttpRequest2-20080930/
Since we're still working on nailing down the details of Access Control
for Cross-Site Requests this dr
Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
>
>
> On Oct 3, 2008, at 2:11 PM, Robert Sayre wrote:
>
> >
> > On Thu, Oct 2, 2008 at 11:43 PM, Maciej Stachowiak <[EMAIL PROTECTED]>
> > wrote:
> >>
> >> A number of WebKit developers (including from the Chrome team and
> >> the Safari
> >> team)
14 matches
Mail list logo
