Now that the responses on this thread have slowed, I would appreciate if
the participants would please summarize where they think we are on this
issue, e.g. the points of agreement and disagreement, how to move
forward, etc.
Also, coming back to the question in the subject (and I apologize if
There are now 11 comments on Web Storage Bug 12111, the last remaining
bug before moving this spec back to Last Call:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12111
If anyone has additional comments, please add them to the bug before the
end of this week.
I would like to get
On May 12, 2011, at 00:49 , Arun Ranganathan wrote:
2. The read methods on FileReader raise a new exception --
OperationNotAllowedException -- if multiple concurrent reads are invoked. I
talked this over with Jonas; we think that rather than reuse DOMException
error codes (like
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12912
Summary: Close status code is an unsigned short
Product: WebAppsWG
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12913
Summary: Close() should throw the same exception as send() for
unpaired surrogates
Product: WebAppsWG
Version: unspecified
Platform: All
URL:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12914
Summary: close() should throw SYNTAX_ERR if the encoded reason
string is too long (protocol supports up to 123 UTF-8
bytes)
Product: WebAppsWG
Version: unspecified
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
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12916
Summary: Default values for code and reason when wasClean is
false
Product: WebAppsWG
Version: unspecified
Platform: All
URL:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12917
Summary: deflate-stream should be an optional extension when
establishing a connection
Product: WebAppsWG
Version: unspecified
Platform: All
URL:
On Wed, Jun 8, 2011 at 8:16 AM, Robin Berjon ro...@berjon.com wrote:
On May 12, 2011, at 00:49 , Arun Ranganathan wrote:
2. The read methods on FileReader raise a new exception --
OperationNotAllowedException -- if multiple concurrent reads are invoked. I
talked this over with Jonas; we
My understanding is that we have reached a proposal which respecifies
the ports argument to postMessage as an array of objects to
transfer, in such a way that we:
- Maintain 100% backward compatibility
- Enhance the ability to pass MessagePorts, so that the object graph
can refer to them as
On Wed, Jun 8, 2011 at 2:24 PM, Kenneth Russell k...@google.com wrote:
My understanding is that we have reached a proposal which respecifies
the ports argument to postMessage as an array of objects to
transfer, in such a way that we:
Array or object? (by object I mean: {transfer:
I prefer continuing to use an array for several reasons: simpler
syntax, better type checking at the Web IDL level, and fewer
ECMAScript-specific semantics.
-Ken
On Wed, Jun 8, 2011 at 2:29 PM, David Levin le...@chromium.org wrote:
On Wed, Jun 8, 2011 at 2:24 PM, Kenneth Russell
I agree with Kenneth.
-Ben Turner
On Wed, Jun 8, 2011 at 2:33 PM, Kenneth Russell k...@google.com wrote:
I prefer continuing to use an array for several reasons: simpler
syntax, better type checking at the Web IDL level, and fewer
ECMAScript-specific semantics.
-Ken
On Wed, Jun 8, 2011 at
On Wed, Jun 8, 2011 at 2:39 PM, David Levin le...@chromium.org wrote:
On Wed, Jun 8, 2011 at 2:33 PM, Kenneth Russell k...@google.com wrote:
I prefer continuing to use an array for several reasons: simpler
syntax, better type checking at the Web IDL level, and fewer
ECMAScript-specific
ok.
On Wed, Jun 8, 2011 at 4:27 PM, Kenneth Russell k...@google.com wrote:
On Wed, Jun 8, 2011 at 2:39 PM, David Levin le...@chromium.org wrote:
On Wed, Jun 8, 2011 at 2:33 PM, Kenneth Russell k...@google.com wrote:
I prefer continuing to use an array for several reasons: simpler
Hi,
A few typos were found in the WARP tests. I have updated them so
hopefully they are now correct.
Kind regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au
On Wed, Jun 8, 2011 at 5:33 PM, Kenneth Russell k...@google.com wrote:
I prefer continuing to use an array for several reasons: simpler
syntax, better type checking at the Web IDL level, and fewer
ECMAScript-specific semantics.
Possibly, but it makes the design of this modification cleaner.
On Wed, Jun 8, 2011 at 4:27 PM, Kenneth Russell k...@google.com wrote:
On Wed, Jun 8, 2011 at 2:39 PM, David Levin le...@chromium.org wrote:
On Wed, Jun 8, 2011 at 2:33 PM, Kenneth Russell k...@google.com wrote:
I prefer continuing to use an array for several reasons: simpler
syntax, better
On Wed, Jun 8, 2011 at 6:14 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Jun 8, 2011 at 4:27 PM, Kenneth Russell k...@google.com wrote:
On Wed, Jun 8, 2011 at 2:39 PM, David Levin le...@chromium.org wrote:
On Wed, Jun 8, 2011 at 2:33 PM, Kenneth Russell k...@google.com wrote:
I prefer
On Wed, Jun 8, 2011 at 9:14 PM, Jonas Sicking jo...@sicking.cc wrote:
This all sounds great to me, but I think we should additionally make
the 'ports' attribute on the MessageEvent interface deprecated.
The only use case for it is to support existing code which doesn't
pass ports in the
On Wed, Jun 8, 2011 at 6:26 PM, Kenneth Russell k...@google.com wrote:
On Wed, Jun 8, 2011 at 6:14 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Jun 8, 2011 at 4:27 PM, Kenneth Russell k...@google.com wrote:
On Wed, Jun 8, 2011 at 2:39 PM, David Levin le...@chromium.org wrote:
On Wed,
22 matches
Mail list logo
