> On Wed, Aug 17, 2016 at 11:38:59, Marijn Kruisselbrink wrote:
> Sorry about that. Somehow that PR slipped through the cracks. I've commented
> on the PR.
>
> Anybody knows what the deal is with the ipr check? What makes it fail, and if
> it fails who is supposed to do what to not make it fail?
The chairs have published details of the Working Group decision
on referencing the Image Description (longdesc) extension in HTML.
In short, most of the CfC carried without objection but there were
some objections related to the longdesc examples.
For convenience, the decision text is pasted
On Thursday, January 28, 2016 7:46 AM, Chaals McCathie Nevile wrote:
> Now we are three co-chairs, we will work between us to fill Art's shoes.
> It won't be easy.
>
> Thanks Art for everything you've done for the group for so long.
Thanks Art. You were there from the first day I showed up at
On Tuesday, April 29, 2014 5:46 AM, Anne van Kesteren wrote:
Both http://www.w3.org/2011/tracking-protection/drafts/tracking-
dnt.html#exceptions-javascript-api
and http://www.w3.org/2011/tracking-protection/drafts/tracking-
dnt.html#exceptions-ww-javascript-api
are inadequate. They need to
On Thursday, December 12, 2013 1:57 PM, Jonas Sicking wrote:
On Thu, Dec 12, 2013 at 1:45 PM, Joel Weinberger j...@chromium.org wrote:
But it would suck if the result is that they create their own form
fields using divs and/or contenteditable.
That's true, although some things like that
Microsoft supports this CfC.
On Wednesday, May 02, 2012 1:20 PM, Arthur Barstow wrote:
As discussed during WebApps' May 1 f2f meeting [2], the Shadow DOM spec
is ready for a First Public Working Draft (FPWD) publication and this a
Call for Consensus (CfC) to do so:
Microsoft supports this call.
On Tuesday, May 1, 2012 9:26 PM, Arthur Barstow wrote:
During WebApps' May 1 discussion about Web Components, a proposal was
made ([1],[2]) to stop work on the XBL2 spec and this is a Call for
Consensus to do do.
If you have any comments or concerns about this
On Tuesday, January 10, 2012 12:34 PM, Arun Ranganathan wrote:
Greetings Adrian,
Sorry for the delay in responding to this email.
Strictly speaking, we could remove the Blob Protocol Version (BLV) [1]. It
isn't returned in getAllResponseHeaders. BLV 's purpose was in case the
protocol
Microsoft is open to adding this to the WebApps charter.
We certainly want to see work on a speech API for user agents proceed at W3C.
Our priorities for the API are 1) a procedural (JavaScript) API and 2) a
declarative syntax for speech recognition and text-to-speech in HTML. We think
WebApps
On Wednesday, December 14, 2011 3:38 AM, Marcos Caceres wrote:
On Wednesday, December 14, 2011 at 1:03 AM, Adrian Bateman wrote:
The current spec requires the opaque string in Blob URLs to be at least
36 characters in length [1]. Our implementation doesn't currently use a
UUID
On Wednesday, December 14, 2011 1:43 AM, Anne van Kesteren wrote:
On Wed, 14 Dec 2011 01:52:04 +0100, Adrian Bateman
adria...@microsoft.com wrote:
This means that you can do something like:
imgElement.src = URL.createObjectURL(blob,false)
and not worry about having to call
On Wednesday, December 14, 2011 2:26 AM, Jonas Sicking wrote:
On Wed, Dec 14, 2011 at 1:42 AM, Anne van Kesteren ann...@opera.com
wrote:
On Wed, 14 Dec 2011 01:52:04 +0100, Adrian Bateman
adria...@microsoft.com wrote:
This means that you can do something like:
imgElement.src
On Wednesday, December 14, 2011 10:46 AM, Glenn Maynard wrote:
We can certainly talk through some of these issues, though the amount of
work we'd need to do doesn't go down. Our proposal is a small change to
the lifetime management of the Blob URL and was relatively simple (for
us) to
Following the discussion we had at TPAC [1], we have uploaded our draft as
an editor's draft to Mercurial:
http://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm
This is just a starting point for discussion and we're looking forward to
incorporating feedback as we move forward. We know
The current spec defines the Blob Protocol Version [1]. Our current
implementation
doesn't require a protocol version and the way protocol handlers are defined in
Internet Explorer does require this. I don't know if this is ever exposed in
the web platform. The spec says that this should be
The current spec requires the opaque string in Blob URLs to be at least
36 characters in length [1]. Our implementation doesn't currently use a
UUID and the length of the string is shorter than 36 characters. While
I have no problem with the recommendation to use UUIDs in the spec,
since it isn't
Another topic that came up at TPAC was readAsBinaryString [1]. This method
predates support for typed arrays in the FileAPI and allows binary data
to be read and stored in a string. This is an inefficient way to store
data now that we have ArrayBuffer and we'd like to not support this method.
At
At TPAC [1,2] I described our proposal for adding an isReusable flag to
createObjectURL. A common pattern we have seen is the need for a blob URL
for a single use (for example, loading into an img element) and then
revoking the URL. This requires a fair amount of boilerplate code to
handle the
On Thursday, December 01, 2011 5:12 AM, Anne van Kesteren wrote:
On Thu, 01 Dec 2011 13:29:37 +0100, Arthur Barstow art.bars...@nokia.com
wrote:
It appears Adrian is proposing:
.../TR/XMLHttpRequest/ be a WG Note but it's not clear to me what
version of XHR would be used: the
On Thursday, November 24, 2011 5:16 AM, Arthur Barstow wrote:
Below, Darin proposes the Pointer Lock [PL] (formerly known as Mouse
Lock) spec and the Gamepad [GP] spec be added to the Web Applications
WG's charter and not the Web Events WG's charter. This is a Call for
Consensus to accept
On Wednesday, November 30, 2011 5:43 AM, Arthur Barstow wrote:
Anne completed his merge XHR and XHR2 merge and the new History section
includes information about the merge. As such, this is a Call for
Consensus to publish a new WD of XHR using the following ED (not yet
pub ready) as the
On Tuesday, November 08, 2011 5:37 AM, Robin Berjon wrote:
On Nov 3, 2011, at 05:38 , Arthur Barstow wrote:
Well, we may get together more frequently than just the annual TPAC meeting
week. If folks think that would be useful (e.g. in 6 months), please speak up
and we can take it from there.
On Friday, November 04, 2011 4:59 PM, Arthur Barstow wrote:
One of the topics discussed this week was to designate a Test Spec
Editor(s) for each of our specs.
We're supportive of this idea.
(BTW, the title of Test Spec Editor is a bit of a straw-man, so
proposals for other titles are also
to drive that change.
Cheers,
Adrian.
On Thursday, September 29, 2011 3:28 PM, Arun Ranganathan wrote:
On 6/6/11 4:36 PM, Adrian Bateman wrote:
On Monday, June 06, 2011 5:56 AM, Arthur Barstow wrote:
Hi Arun, Jonas, All,
The last publication of the File API spec [ED] was last October so
There has been discussion in this group now and again about the need for stream
support as part of the File APIs including recently in the threads about
Streaming
Blobs [1] and XHR streaming [2]. I've also had several private conversations
with
members of the WG about the need we see for this
Microsoft supports this call.
On Tuesday, September 20, 2011 4:05 AM, Arthur Barstow wrote:
This is a Call for Consensus to publish a Last Call Working Draft of the
Web Socket API using the following document as the basis:
http://dev.w3.org/html5/websockets/
As noted in [1], this spec
Today we shipped Microsoft Internet Explorer 10 Platform Preview 3 as part of
the Windows 8 Developer Preview. Alongside this release, we have submitted
interop tests for several WebApps specs for review by the working group:
WebSockets API (101 tests/assertions)
Changeset:
On Wednesday, September 07, 2011 9:53 AM, Arthur Barstow wrote:
It appears the majority of the people that voiced an opinion on this
thread prefer DOM4.
If anyone objects to DOM4, please speak up by September 9 at the latest
and include the rationale for your objection as well as an
On Monday, August 15, 2011 2:22 AM, Anne van Kesteren wrote:
On Thu, 04 Aug 2011 21:21:46 +0200, Anne van Kesteren ann...@opera.com
wrote:
On Thu, 04 Aug 2011 21:06:58 +0200, Adrian Bateman
adria...@microsoft.com wrote:
The name was changed. We weren't terribly keen on the change
On Thursday, August 11, 2011 3:29 AM, Arthur Barstow wrote:
[ Topic changed to how to organize the group's DOM specs ... ]
Hi Adrian, Anne, Doug, Jacob, All,
The WG is chartered to do maintenance on the DOM specs so a question for
us is how to organize the DOM specs, in particular, whether
On Wednesday, August 10, 2011 10:18 AM, Arthur Barstow wrote:
Anne, Ms2ger, All,
Anne and others proposed in [Proposal] the DOM 2 View Recommendation
[D2V] be rescinded. The rescinding process is defined in the Process
Document [Rescind]. However, Ian Jacobs just indicated in IRC
Microsoft supports this CfC.
On Tuesday, July 26, 2011 7:13 AM, Arthur Barstow wrote:
The pre-LC comment period for Progress Events resulted in no comments
[1]. As such, Anne proposes a new LC be published and this is a CfC to
do so:
http://dev.w3.org/2006/webapi/progress/
This CfC
On Monday, July 25, 2011 1:32 PM, Aryeh Gregor wrote:
On Thu, Jul 21, 2011 at 1:02 PM, Adrian Bateman adria...@microsoft.com
wrote:
For platform features that directly affect web developers' pages that might
sometimes be true. However, compression is also optional in HTTP and it
doesn't
On Thursday, July 21, 2011 8:31 AM, Anne van Kesteren wrote:
On Thu, 21 Jul 2011 17:26:21 +0200, Arthur Barstow art.bars...@nokia.com
wrote:
What do others (Anne?, Maciej?, ...) think about this issue?
I don't know enough about the WebSocket protocol, but optional web
platform features
On Thursday, July 21, 2011 12:33 PM, Ian Hickson wrote:
On Thu, 21 Jul 2011, Adrian Bateman wrote:
For platform features that directly affect web developers' pages that
might sometimes be true. However, compression is also optional in HTTP
and it doesn't appear to have caused problems
-- base64 encoding otherwise
only works on DOMString.
I'd like to see both proposals implemented... Then I get everything!
On Jul 11, 2011, at 12:21 PM, Adrian Bateman adria...@microsoft.com wrote:
It requires more work for us. Our createObjectURL doesn't require that
abstraction.
The difference
On Monday, July 18, 2011 12:52 PM, Michael Nordman wrote:
The problem is around naming the binary parts attached to
multi-part-form-encoded
FormData. I think I'm in favor of the more direct solution to this problem,
providing a FormData.append() variant that optionally allows the caller to
On 11 July 2011 10:53, Jonas Sicking wrote:
On Mon, Jul 11, 2011 at 10:12 AM, Adrian Bateman adria...@microsoft.com wrote:
Some content management systems use the original filename by default
when storing files in document libraries. It's certainly a lesser use case
but seems like
From: Charles Pritchard
Sent: 11-Jul-11 12:03 PM
To: Adrian Bateman
Cc: Jonas Sicking; Anne van Kesteren; Julian Reschke; Alfonso Martínez de
Lizarrondo; Webapps WG
Subject: Re: [XHR2] Blobs, names and FormData
getFile could work with dataTransfer for dropping files onto the desktop
On Thursday, July 07, 2011 10:21 PM, Arun Ranganathan wrote:
On 7/6/11 10:13 PM, Cameron McCormack wrote:
There was a recent change in Web IDL which made interface types (like
the readAsXXX argument types) not include null by default, and if you
want to allow null, to write it as “Type?”.
On Friday, July 08, 2011 1:12 PM, Ian Hickson wrote:
12917 - deflate-stream should be an optional extension when
establishing a connection
Resolved, WontFix
MICROSOFT PROPOSAL: We strongly disagree with the API spec overruling
the protocol spec
on what is optional in the protocol. The
Microsoft supports publishing a Last Call working draft of the Web IDL spec.
We believe that the spec is feature complete and meets the requirements below.
While we have a few reservations about Exceptions and share some of the concerns
voiced in the separate thread on that topic, we believe that
We're keen to resolve the remaining issues with the WebSockets API and have a
timetable
to get to Candidate Recommendation. From informal conversations we've had, we
believe
other browser vendors share this goal. I think the current WebSocket API is
feature
complete and meets the requirements
On Thursday, July 07, 2011 3:55 PM, Jonas Sicking wrote:
On Thu, Jul 7, 2011 at 3:00 PM, Adrian Bateman adria...@microsoft.com wrote:
12917 - deflate-stream should be an optional extension when establishing
a connection
Resolved, WontFix
MICROSOFT PROPOSAL: We strongly disagree
Just catching up with this thread. We ran into the same problem last week while
investigating FormData and XHR. Since FormData is designed to allow XHR to
interact
with existing form end-points that usually required a navigation, we've found
that
few of them have been tested with empty
http://dev.w3.org/2006/webapi/FileAPI/#reading-a-file
What is the expected behaviour for FileReader.readAsXXX(null)? Currently
I think both IE10 and Chrome fail silently and there are no events fired
whereas Firefox appears to throw an internal NS_ERROR_INVALID_POINTER
exception.
The spec
On Wednesday, June 22, 2011 3:24 PM, James Robinson wrote:
On Wed, Jun 22, 2011 at 2:42 PM, Aryeh Gregor simetrical+...@gmail.com
wrote:
On Mon, Jun 20, 2011 at 10:50 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Note that there are currently major browsers that do not follow the spec
as
On Friday, June 10, 2011 7:05 AM, Arthur Barstow wrote:
Adrian - this bug is for the Web Sockets API spec (and not Web Storage),
correct?
On Jun/8/2011 1:21 PM, ext bugzi...@jessica.w3.org wrote:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12913
Yes - corrected now, thanks!
On Tuesday, June 07, 2011 10:36 AM, Ian Hickson wrote:
On Tue, 7 Jun 2011, Adrian Bateman wrote:
This check-in [1] reintroduces the onerror handler that was removed
previously [2]. Since, in general, WebSocket protocol errors are fatal
and result in onclose, what is the purpose of adding
On Tuesday, June 07, 2011 10:36 AM, Ian Hickson wrote:
On Tue, 7 Jun 2011, Adrian Bateman wrote:
We have removed onerror from our implementation since the previous
change and it's frustrating trying track against the spec with
unexpected updates.
That's the cost of being on the bleeding
I'm pleased to see the changes in the WebSockets API for binary message support.
I'm a little confused by this text:
When a WebSocket object is created, its binaryType IDL attribute must
be set to the Blob interface object associated with the same global
object as the WebSocket
On Friday, May 27, 2011 4:23 PM, Jonas Sicking wrote:
However, I think there might be another solution to this whole
situation. There really is no reason that only binary data can be
received as a Blob. Getting data as a Blob is useful any time you're
dealing with a large chunk of data where
On Friday, May 27, 2011 4:30 PM, Ian Hickson wrote:
On Fri, 27 May 2011, Jonas Sicking wrote:
For example, what is an implementation supposed
to do if a page does:
ws.binaryType = otherwindow.ArrayBuffer
or
otherwindow.useThis(ws);
with other window containing
function
As I proposed in March [1], we think it makes sense to separate the WebSocket
constructor from the operation to initiate the network operation. We proposed a
separate open() method similar to XHR. This allows a WebSocket object to be
constructed and initialised prior to communication. We think
First, thanks to Art for pulling all this content together. We're looking
forward to a more structured process for testing as various specifications
in the WebApps increase in maturity.
I have a couple of small comments related to the issues Aryeh raised.
Apologies for the lateness of these
On Friday, April 15, 2011 2:41 PM, Jonas Sicking wrote:
On Fri, Apr 15, 2011 at 12:53 PM, Adrian Bateman adria...@microsoft.com
wrote:
Yes, we could live with it but the semantics are more complex. Is this the
same as calling abort() then readAsXXX()?
Yes. I.e. the semantics of readAsX
On Monday, April 18, 2011 12:04 PM, Jonas Sicking wrote:
On Mon, Apr 18, 2011 at 9:02 AM, Adrian Bateman adria...@microsoft.com
wrote:
On Friday, April 15, 2011 2:41 PM, Jonas Sicking wrote:
Yes. I.e. the semantics of readAsX is basically:
readAsX(...) {
if (requestInProgress
On Tuesday, April 12, 2011 12:08 PM, Jonas Sicking wrote:
FileReader is extremely similar to XMLHttpRequest. The main difference
is in how you initiate the request (.open/.send vs. .readAsX). This
similarity is even getting stronger now that XHR gets .result.
So I think there are good
On Friday, April 15, 2011 12:16 PM, Arun Ranganathan wrote:
On 4/15/11 2:57 PM, Adrian Bateman wrote:
With this in mind, I don't personally have a strong feeling either way
between having to call abort() explicitly or having readAsXXX implicitly
call abort(). I've discussed it with others
On Monday, April 11, 2011 8:28 AM, Arun Ranganathan wrote:
On 3/31/11 6:12 PM, Eric Uhrhane wrote:
I think it's cleaner and simpler just to throw. FileReader and XHR
are already different enough that a bit more, as long as it's a
usability improvement, isn't a big deal. The efficiency
On Monday, April 11, 2011 10:23 AM, Eric Uhrhane wrote:
On Mon, Apr 11, 2011 at 9:33 AM, Arun Ranganathan a...@mozilla.com wrote:
In general, I'm averse to throwing, since I think it puts an additional
burden on the developer (to catch, for example).
I don't think so. I think that calling
On Saturday, April 09, 2011 4:23 AM, Arthur Barstow wrote:
The Editors of the Indexed Database API would like to publish a new
Working Draft of their spec and this is a Call for Consensus to do so:
http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html
If one agrees with this
On Tuesday, April 05, 2011 4:27 AM, Arthur Barstow wrote:
Hi All,
What needs to be done before the WebSocket API is LC ready?
Bugzilla has three open bugs for this spec:
1. API for send/receive of binary data? Current IETF protocol drafts
have binary type. Consider typed arrays
On Thursday, March 31, 2011 10:19 AM, Arun Ranganathan wrote:
On 3/30/11 2:01 PM, Eric Uhrhane wrote:
On Mon, Mar 28, 2011 at 5:37 PM, Adrian Batemanadria...@microsoft.com
wrote:
Is there a reason for the current spec text?
I don't know the original rationale, but in the absence of any
text?
Thanks,
Adrian.
--
Adrian Bateman
Program Manager - Internet Explorer - Microsoft Corporation
Phone: +1 (425) 538 5111
Email: mailto:adria...@microsoft.com
Microsoft supports this.
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On
Behalf Of Arthur Barstow
Sent: Wednesday, March 02, 2011 4:08 AM
To: public-webapps
Subject: CfC: publish Last Call Working Draft of Progress Events spec; deadline
March 7
Given no comments
Apologies for missing the March 7 deadline. We tried to carry out a detailed
pre-Last
Call review and have the following feedback. Microsoft would like to discuss
these
points before moving the Last Call.
Thanks,
Adrian.
Feedback on latest draft of Web Workers
Based on our understanding of
Microsoft supports this CfC.
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On
Behalf Of Arthur Barstow
Sent: Thursday, March 03, 2011 5:26 AM
To: public-webapps
Cc: Mark Nottingham; Julian Reschke; Nikunj Mehta
Subject: CfC: to stop work on Programmable HTTP Caching
On Friday, February 25, 2011 1:54 AM, Anne van Kesteren wrote:
The idea is to provide a better definition of the events model at a more
appropriate location. I do not think DOM Level 3 Events is the right way
forward, but I am happy to work in parallel to see which turns out
better in the
On Wednesday, February 23, 2011 8:21 AM, Arthur Barstow wrote:
Anne and Ms2ger (representing Mozilla Foundation) have continued to work
on the DOM Core spec and they propose publishing a new Working Draft of
the spec:
http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html
As such, this
As we've been updating our WebSockets prototype [1] in line with the latest
protocol
changes we've been thinking about how the binary support that the protocol now
includes should be reflected in the API. I added the following comment to the
bug:
At Microsoft, we've been reviewing how the
On Thursday, February 24, 2011 2:37 PM, Anne van Kesteren wrote:
On Thu, 24 Feb 2011 19:26:19 +0100, Adrian Bateman
adria...@microsoft.com wrote:
I'm concerned about the working group endorsing a working draft with
phrasing like The timeStamp attribute must be useless. I understand
On Wednesday, November 24, 2010 3:01 AM, Jeremy Orlow wrote:
For over a year now, the WebStorage spec has stipulated that
Local/SessionStorage store and retrieve objects per the structured clone
algorithm rather than strings. And yet there isn't a single implementation
who's implemented this.
On Tuesday, November 16, 2010 8:11 AM, Jonas Sicking wrote:
On Tuesday, November 16, 2010, Anne van Kesteren ann...@opera.com
wrote:
On Tue, 16 Nov 2010 01:35:05 +0100, Jonas Sicking jo...@sicking.cc
wrote:
Ok, here is what I'll propose as the final solution:
FileAPI will define the
On Thursday, November 11, 2010 11:47 AM, Jonas Sicking wrote:
Oh, definitely, we still need the createObjectURL/revokeObjectURL
functions. Sorry, that was probably unclear.
However we're still left without a place to put them. Maybe it's as
simple as putting them on the document object? That
Microsoft supports publication of a FPWD of Web Messaging.
On Saturday, November 06, 2010 11:49 AM, Arthur Barstow wrote:
Ian, All - during WebApps' November 1 gathering, participants expressed
in an interest in publishing a First Public Working Draft of Web
Messaging [1] and this is a CfC to
On Tuesday, September 07, 2010 11:46 AM, Chris Prince wrote:
1. Most people that I talk to dislike the name Blob, much less having
it spread to things like BlobReader.
I could maybe understand this if blob were a new term we were
inventing. But it's not. It's a well-known computer
On Monday, August 30, 2010 1:09 PM, Jonas Sicking wrote:
On Mon, Aug 30, 2010 at 9:59 AM, Arun Ranganathan a...@mozilla.com
wrote:
*sigh. Naming continues to be hard. Not everyone's thrilled with the
proliferation of Blob in the API [1] including other major implementors
(my co-editor
On Monday, July 12, 2010 2:31 PM, Darin Fisher wrote:
On Mon, Jul 12, 2010 at 9:59 AM, David Levin le...@google.com wrote:
On Mon, Jul 12, 2010 at 9:54 AM, Adrian Bateman adria...@microsoft.com
wrote:
I read point #5 to be only about surviving the start of a navigation. As a
web developer
On Monday, July 12, 2010 8:24 AM, David Levin wrote:
On Mon, Jul 12, 2010 at 5:47 AM, Adrian Bateman adria...@microsoft.com
wrote:
Making the blob url identical to the lifetime of the blob itself would
expose when garbage collection takes place and in general could lead to
easy to make
On Monday, July 12, 2010 9:32 AM, David Levin wrote:
On Mon, Jul 12, 2010 at 8:39 AM, Adrian Bateman adria...@microsoft.com
wrote:
The behaviour would have to be explicitly specified and not left to depend on
indeterminate browser implementations.
Yes. Unfortunately, another way of saying
On Monday, June 28, 2010 2:47 PM, Arun Ranganathan wrote:
On 6/23/10 9:50 AM, Jian Li wrote:
I think encoding the security origin in the URL allows the UAs to do
the security origin check in place, without routing through other
authority to get the origin information that might cause the
On Friday, June 11, 2010 11:18 AM, Jonas Sicking wrote:
On Fri, Jun 11, 2010 at 11:11 AM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Jun 11, 2010 at 9:09 AM, Adrian Bateman adria...@microsoft.com
It's not clear to me the benefit of encoding the origin into the URL. Do
we expect script
On Tuesday, June 22, 2010 3:37 PM, Arun Ranganathan wrote:
On 6/22/10 8:44 AM, Adrian Bateman wrote:
I think it makes more sense for the URL to be opaque and let user
agents figure
out the optimal way of implementing origin and other checks.
I think it may be important to define
On Tuesday, June 22, 2010 8:40 PM, David Levin wrote:
I agree with you Adrian that it makes sense to let the user agent figure
out the optimal way of implementing origin and other checks.
A logical step from that premise is that the choice/format of the
namespace specific string should be
On Wednesday, June 02, 2010 5:27 PM, Arun Ranganathan wrote:
On 6/2/10 5:06 PM, Jian Li wrote:
Indeed, the URL scheme seems to be more sort of implementation details.
Different browser vendors can choose the appropriate scheme, like Mozilla
ships with moz-filedata. How do you think?
On Wednesday, June 02, 2010 5:35 PM, Jonas Sicking wrote:
On Wed, Jun 2, 2010 at 5:26 PM, Arun Ranganathan a...@mozilla.com wrote:
On 6/2/10 5:06 PM, Jian Li wrote:
In addition,
we're thinking it will probably be a good practice to encode the security
origin in the blob URL scheme, like
On Wednesday, May 26, 2010 1:05 PM, Adam Barth wrote:
On Wed, May 26, 2010 at 9:08 AM, Tyler Close tyler.cl...@gmail.com wrote:
On Mon, May 24, 2010 at 8:23 AM, Adrian Bateman adria...@microsoft.com
wrote:
In IE, we only support Access-Control-Allow-Origin and combining with
other values
In IE, we only support Access-Control-Allow-Origin and combining with other
values (albeit optional ones) that we don't support might be misleading. It
also introduces some additional parsing that changes the behaviour from a
simple comparison to a more complex parse and then compare.
We
At Microsoft, we don't believe the spec is quite ready for Last Call. Based on
our prototyping work, we're preparing some additional feedback that we think is
more substantive than would be appropriate for Last Call comments. I anticipate
that we will be able to post this feedback to the
.
On Dec 21, 2009, at 6:58 PM, Adrian Bateman wrote:
On Monday, December 21, 2009 6:43 PM, I wrote:
Microsoft supports publishing a new Working Draft.
However, there appears to be a problem with the Respec.js script at
http://dev.w3.org/2006/webapi/WebSimpleDB/.
Apparently, the script
Microsoft supports publishing a new Working Draft.
However, there appears to be a problem with the Respec.js script at
http://dev.w3.org/2006/webapi/WebSimpleDB/.
On Monday, December 14, 2009 12:54 PM, Arthur Barstow wrote:
This is a Call for Consensus (CfC) to publish a new Working Draft of
On Monday, December 21, 2009 6:43 PM, I wrote:
Microsoft supports publishing a new Working Draft.
However, there appears to be a problem with the Respec.js script at
http://dev.w3.org/2006/webapi/WebSimpleDB/.
Apparently, the script takes some time to run (at least when I tried it in
On Saturday, December 12, 2009 11:27 AM, Arun Ranganathan wrote:
Charles McCathieNevile wrote:
On Mon, 07 Dec 2009 16:46:12 -0800, Arthur Barstow
art.bars...@nokia.com wrote:
This is a Call for Consensus (CfC) to publish a Last Call Working
Draft of the following specs:
1.
On Friday, November 20, 2009 4:44 AM, Charles McCathieNevile wrote:
On Fri, 20 Nov 2009 06:23:38 +0100, Adrian Bateman
adria...@microsoft.com wrote:
...As I noted at TPAC, at Microsoft we don't think we'll collectively
be able to achieve reasonable interop because of the SQL dialect issue
Apologies for only sending this at the deadline. I have been collecting
feedback from a number of different groups at Microsoft who have been reviewing
the WebSockets API spec and only had chance to collate it today.
Feedback on Web Sockets API (draft dated 29 October 2009)
1) In the WebSocket
On Wednesday, November 18, 2009 2:51 PM, Charles McCathieNevile wrote:
I think it make sense to clarify in working drafts that this spec is
unlikely to be interoperable across the web at large, but is usable for
various specific systems.
I don't think it makes sense to just turn it into a
On Monday, November 02, 2009 10:12 PM, Jonas Sicking wrote:
On Mon, Nov 2, 2009 at 12:25 PM, Adrian Bateman
adria...@microsoft.com wrote:
On Tuesday, October 27, 2009 2:35 PM, Jonas Sicking wrote:
But like Arun, I suspect that this feature is the most controversial
in the spec. Apple
On Tuesday, November 03, 2009 10:07 AM, Arun Ranganathan wrote:
Adrian Bateman wrote:
On Monday, November 02, 2009 10:12 PM, Jonas Sicking wrote:
Are you concerned about security bugs in the feature design or in
the implementation?
Mostly in the implementation - it increases the surface
On Tuesday, October 27, 2009 2:35 PM, Jonas Sicking wrote:
On Tue, Oct 27, 2009 at 12:36 AM, Ian Hickson i...@hixie.ch wrote:
I would like to see implementation feedback on this. I don't
understand
why we would want to assign semantics to urn:uuid: URLs that are so
specific -- that seems
1 - 100 of 111 matches
Mail list logo
