https://www.w3.org/Bugs/Public/show_bug.cgi?id=15293
Summary: HTTP/1.1 101 Web Socket Protocol Handshake Upgrade:
WebSocket Connection: Upgrade WebSocket-Origin:
http://www.cnodejs.org WebSocket-Location:
Hi
http://www.w3.org/TR/file-system-api/#widl-FileEntry-file
says that successCallback is A callback that is called with the
newFileWriter. there should be A callback that is called with the File
BTW was trying to file that bug myself, but I could not find suitable
component in WebAppsWG
Hi,
(Sorry for my slow response, I'm in a half-vacation status)
On Sun, Dec 18, 2011 at 12:19 AM, Charles McCathieNevile
cha...@opera.comwrote:
On Fri, 16 Dec 2011 10:10:45 +0100, Kinuko Yasuda kin...@chromium.org
wrote:
On Thu, Dec 15, 2011 at 9:19 PM, Arthur Barstow art.bars...@nokia.com
As fun as this is, all this mud slinging is really not getting us anywhere
useful.
Lets go back an look at the options we have to divorce Widgets/XML Dig Sig
from Elliptic Curve:
1. Remove ECC from XML Dig Sig (in my opinion, the right thing to do™):
pros:
- frees both XML
Hi Brona,
For mostly historical reasons, WebApps' File* specs still use Tracker
rather than Bugzilla (and IIRC, Arun also uses the list archive as well
as the spec itself to track issues for the File API spec):
http://www.w3.org/2008/webapps/track/products
For consistency, it would be
Hi Arthur,
I do not need them :) that's mainly for editors to keep track in one
place :)
I just suggest this bug to be fixed and it's silly to spam whole forum
because of it :)
(I do not have access to file a bug in this W3C tracking tool)
Brona
On 21.12.2011 13:05, Arthur Barstow wrote:
TLR, FH, XMLSecWG,
On 12/21/11 6:03 AM, ext Marcos Caceres wrote:
Lets go back an look at the options we have to divorce Widgets/XML Dig Sig
from Elliptic Curve:
1. Remove ECC from XML Dig Sig (in my opinion, the right thing to do™):
pros:
- frees both XML Dig Sig and Widgets
Are any user agents other than IE8+ currently implementing or have
implemented XHR2 timeout?
https://bugs.webkit.org/show_bug.cgi?id=74802
I have a couple of things I wanted to question, which may or may not result
in clarification in the spec.
1. The spec says the timeout should fire after
On Wed, 21 Dec 2011 16:25:33 +0100, Jarred Nicholls jar...@webkit.org
wrote:
1. The spec says the timeout should fire after the specified number of
milliseconds has elapsed since the start of the request. I presume this
means literally that, with no bearing on whether or not data is coming
On Wed, Dec 21, 2011 at 10:47 AM, Anne van Kesteren ann...@opera.comwrote:
On Wed, 21 Dec 2011 16:25:33 +0100, Jarred Nicholls jar...@webkit.org
wrote:
1. The spec says the timeout should fire after the specified number of
milliseconds has elapsed since the start of the request. I presume
Hi Art,
the pessimistic XMLSECPAG chair told you that it wouldn't resolve within days.
But I hope to have a clear view and plan by the end of January. Executing that
plan may take some time. Plan is to resolve until end of March, if everything
goes well. Well meaning a decision of the PAG and
On Tue, Dec 20, 2011 at 5:38 PM, Brian Kardell bkard...@gmail.com wrote:
Yes, I had almost the same thought, though why not just require a prefix?
I also think some examples actually showing some handling of events and use
of css would be really helpful here... The upper boundary for css vs
Bronislav:
Thanks for the tip; it's already fixed in the latest editor's
draft, so the fix will get published the next time the document is.
See the latest at
http://dev.w3.org/2009/dap/file-system/file-dir-sys.html.
Eric
On Wed, Dec 21, 2011 at 12:21 AM, Bronislav Klučka
There are a number of standard headers that aren't listed as simple
headers but which I am suspecting are allowed in any case via some
other principle:
Accept-Charset
Accept-Encoding
Connection
Host
Referer
User-Agent
Cookie
Is this true or some or all of these? If so, how was I supposed to
On 12/21/2011 05:59 PM, Jarred Nicholls wrote:
On Wed, Dec 21, 2011 at 10:47 AM, Anne van Kesteren ann...@opera.com
mailto:ann...@opera.com wrote:
On Wed, 21 Dec 2011 16:25:33 +0100, Jarred Nicholls
jar...@webkit.org mailto:jar...@webkit.org wrote:
1. The spec says the timeout
On Wed, Dec 21, 2011 at 1:34 PM, Olli Pettay olli.pet...@helsinki.fiwrote:
On 12/21/2011 05:59 PM, Jarred Nicholls wrote:
On Wed, Dec 21, 2011 at 10:47 AM, Anne van Kesteren ann...@opera.com
mailto:ann...@opera.com wrote:
On Wed, 21 Dec 2011 16:25:33 +0100, Jarred Nicholls
On Wed, 21 Dec 2011 19:24:19 +0100, Benson Margulies
bimargul...@gmail.com wrote:
There are a number of standard headers that aren't listed as simple
headers but which I am suspecting are allowed in any case via some
other principle:
Accept-Charset
Accept-Encoding
Connection
Host
Referer
On 12/21/2011 08:59 PM, Jarred Nicholls wrote:
On Wed, Dec 21, 2011 at 1:34 PM, Olli Pettay olli.pet...@helsinki.fi
mailto:olli.pet...@helsinki.fi wrote:
On 12/21/2011 05:59 PM, Jarred Nicholls wrote:
On Wed, Dec 21, 2011 at 10:47 AM, Anne van Kesteren
ann...@opera.com
On Wed, Dec 21, 2011 at 1:34 PM, Olli Pettay olli.pet...@helsinki.fiwrote:
xhr.onprogress = function() {
this.timeout += 250;
}
What if a UA suspends scripts in background pages (eg. to save battery),
but allows XHR requests to continue? This would time out as soon as that
happened.
This
On Wed, Dec 21, 2011 at 2:20 PM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Dec 21, 2011 at 1:34 PM, Olli Pettay olli.pet...@helsinki.fiwrote:
xhr.onprogress = function() {
this.timeout += 250;
}
What if a UA suspends scripts in background pages (eg. to save battery),
but allows XHR
On Wed, Dec 21, 2011 at 2:25 PM, Jarred Nicholls jar...@webkit.org wrote:
You sound really self-conflicted based on how you started your message vs.
how you ended it.
Please be less vague.
--
Glenn Maynard
On Wed, Dec 21, 2011 at 2:15 PM, Olli Pettay olli.pet...@helsinki.fiwrote:
On 12/21/2011 08:59 PM, Jarred Nicholls wrote:
On Wed, Dec 21, 2011 at 1:34 PM, Olli Pettay olli.pet...@helsinki.fi
mailto:Olli.Pettay@helsinki.**fi olli.pet...@helsinki.fi wrote:
On 12/21/2011 05:59 PM, Jarred
(11/12/21 23:47), Anne van Kesteren wrote:
On Wed, 21 Dec 2011 16:25:33 +0100, Jarred Nicholls
jar...@webkit.org wrote:
1. The spec says the timeout should fire after the specified number of
milliseconds has elapsed since the start of the request. I presume
this means literally that, with no
On Wed, Dec 21, 2011 at 2:55 PM, Jarred Nicholls jar...@webkit.org wrote:
On Wed, Dec 21, 2011 at 1:59 PM, Jarred Nicholls jar...@webkit.org
wrote:
1. Clean code, which is better for authors and the web platform. To
achieve the same results as a native dataTimeout, your snippet
On Wed, Dec 21, 2011 at 3:54 PM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Dec 21, 2011 at 2:55 PM, Jarred Nicholls jar...@webkit.orgwrote:
On Wed, Dec 21, 2011 at 1:59 PM, Jarred Nicholls jar...@webkit.org
wrote:
1. Clean code, which is better for authors and the web platform.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15306
Summary: [XHR] (editorial) Mark the event summary section as
non-normative.
Product: WebAppsWG
Version: unspecified
Platform: PC
OS/Version: All
Status: NEW
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15307
Summary: [XHR] (editorial) the Extensibilty section suggest
method prefixing like FooBar() instead of fooBar()
Product: WebAppsWG
Version: unspecified
Platform: PC
Chrome sends:
Access-Control-Request-Headers:Origin, Content-Type, Accept
Is that just wrong?
On 12/21/11 9:43 PM, Benson Margulies wrote:
I just made a small discovery;
Chrome 16 sends, e.g.
Access-Control-Request-Headers: Content-Type
Firefox 8.0 sends, contrastively:
Access-Control-Request-Headers: content-type
Given the requirement for case-sensitive comparison in the spec
bcc: HTML WG, HTML Data Task Force, Web Apps WG, RDF WG, W3C TAG, SWCG,
SVG WG, and PFWG
This e-mail is to notify the liaison groups that are listed in the RDF
Web Apps Working Group charter that the RDF Web Apps WG will be taking
the RDFa 1.1 specs into what it hopes to be their final Last Call
On Wed, Dec 21, 2011 at 9:16 PM, Benson Margulies bimargul...@gmail.comwrote:
Chrome sends:
Access-Control-Request-Headers:Origin, Content-Type, Accept
Is that just wrong?
The spec clearly says: author request headers: A list of headers set by
authors for the request. Empty, unless
The spec makes it very succinct in its preflight request steps that
Allow-Access-Request-Method should be sent, always. However in WebKit and
Firefox I'm observing this header only being sent when there are author
request headers being sent in Allow-Access-Request-Headers. Is the spec
not clear
On Wed, Dec 21, 2011 at 11:09 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 12/21/11 11:04 PM, Jarred Nicholls wrote:
The spec makes it very succinct in its preflight request steps that
Allow-Access-Request-Method should be sent, always.
There is no such thing. What header did you actually
I'll try this again...
The spec makes it very succinct in its preflight request steps that
Access-Control-Request-Method should be sent, always. However in WebKit
and Firefox I'm observing this header only being sent when there are
author request headers being sent in
On 12/21/11 11:28 PM, Jarred Nicholls wrote:
I'll try this again...
The spec makes it very succinct in its preflight request steps that
Access-Control-Request-Method should be sent, always. However in WebKit
and Firefox I'm observing this header only being sent when there are
author request
On Wed, Dec 21, 2011 at 11:37 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 12/21/11 11:28 PM, Jarred Nicholls wrote:
I'll try this again...
The spec makes it very succinct in its preflight request steps that
Access-Control-Request-Method should be sent, always. However in WebKit
and
36 matches
Mail list logo
