I have a non resolvable conflict on November 11 so there will be no
widgets call that day.
A higher priority item is completing the round-trip comment loop from
the I18N WG's comment on the September 7 Widget Interface LCWD:
http://www.w3.org/TR/2010/WD-widgets-apis-20100907/
On Nov/6/2010 6:09 PM, ext Ian Hickson wrote:
On Sat, 6 Nov 2010, Arthur Barstow wrote:
[...] suggested the spec be published as a Working Group Note and this
is Call for Consensus to do.
I support this in principle.
OK.
I can't commit to providing the draft,
though. A few months ago I
On Wed, 10 Nov 2010, Arthur Barstow wrote:
Are there any normative edits/changes that must be made to the doc
before it is published as a WG note?
I'm not aware of any.
Regarding the non-normative W3C boilerplate (e.g. Status of the
Document), Mike Smith indicated he is willing to work
On 11/9/2010 12:35 AM, Jonas Sicking wrote:
One thing we could do is to move
.source
.transaction
.result
.error
to IDBRequest. Then make success and error events be simple events
which only implement the Event interface. I.e. we could get rid of the
IDBEvent, IDBSuccessEvent,
On Wed, Nov 10, 2010 at 10:38 AM, Shawn Wilsher sdwi...@mozilla.com wrote:
On 11/9/2010 12:35 AM, Jonas Sicking wrote:
One thing we could do is to move
.source
.transaction
.result
.error
to IDBRequest. Then make success and error events be simple events
which only implement the Event
* Jonas Sicking wrote:
It was brought up by Billy Hoffman (http://zoompf.com) that some web
applications have very sensitive sessions and they are set up to expire the
session (ie, log the person out) if a request is received that has no
session cookie header in it, etc. The assertion was that
Personally, I don't think new response modes is the proverbial straw
that breaks the camel's back.
I don't see the problem with selecting the responseType up front
either. It doesn't feel like a new class of object is warranted just
to provide the response body different forms. As Jonas pointed
On Wed, 10 Nov 2010 21:40:01 +0100, Bjoern Hoehrmann derhoe...@gmx.net
wrote:
You can expire the client-side part of the session without knowing which
session it is, so long as the browser reads the Set-Cookie header in the
response. You could simply respond with an expired Set-Cookie header to
I don't have a strong preference either way (adding responseType to XHR, or
creating a new BinaryHttpRequest).
If we do choose the responseType approach, should its value be an enum, or a
string?
Chris
On Wed, Nov 10, 2010 at 12:44 PM, Michael Nordman micha...@google.comwrote:
Personally, I
On Tue, Nov 9, 2010 at 12:03 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Nov 9, 2010 at 11:54 AM, Chris Rogers crog...@google.com wrote:
Hi David,
Sorry for the delayed response. I think the idea of BinaryHttpRequest is a
reasonable one. As you point out, it simply side-steps any
* David Flanagan wrote:
Is this a fair summary of this thread?
Chris (Apple) worries that having to support both responseText and
responseArrayBuffer will be memory inefficient because implementations
will end up with both representations in memory.
James (Google) worries that synchronously
On Wed, Nov 10, 2010 at 1:43 PM, Pablo Castro
pablo.cas...@microsoft.com wrote:
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On
Behalf Of bugzi...@jessica.w3.org
Sent: Monday, November 08, 2010 5:07 PM
So what happens if trying save in an object store which has
From: Tab Atkins Jr. [mailto:jackalm...@gmail.com]
Sent: Wednesday, November 10, 2010 1:50 PM
On Wed, Nov 10, 2010 at 1:43 PM, Pablo Castro
pablo.cas...@microsoft.com wrote:
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org]
On Behalf Of bugzi...@jessica.w3.org
On Wed, Nov 10, 2010 at 1:39 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote:
* David Flanagan wrote:
Is this a fair summary of this thread?
Chris (Apple) worries that having to support both responseText and
responseArrayBuffer will be memory inefficient because implementations
will end up with
After discussion with Anne and James, I retract my support for a new
constructor. I'm in favor of .responseType.
Specifically, .responseType would take values like (for legacy
treatment) / text / document / arraybuffer / blob / etc. If
the value is , then .responseText and .responseXML
On Wed, Nov 10, 2010 at 1:50 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Nov 10, 2010 at 1:43 PM, Pablo Castro
pablo.cas...@microsoft.com wrote:
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org]
On Behalf Of bugzi...@jessica.w3.org
Sent: Monday, November
* Jonas Sicking wrote:
In most cases you do not need to store the bytes in order to get them
back, you can just apply the character encoding scheme used to decode
the bytes to the string and you'll have the original byte string, so
long as the character encoding scheme is bijective, which is
Actually, we could go even further and disallow paths entirely, and
just allow a property name. That is what the firefox implementation
currently does. That also sidesteps the issue of missing parents.
I'm not convinced that people are going to bury their key several
levels deep on the
Ah okay. So that would never work. As things tagged with anonymous,
XMLHttpRequest without credentials, or AnonXMLHttpRequest would ignore
Set-Cookie headers.
First of all, a CORS xhr request could be made with credentials (since
they're available in the view-source JavaScript)... the
What do databases usually do with columns that use autoincrement but a
value is still supplied? My recollection is that that is generally
allowed?
You can normally insert with a supplied key providing it is unique.
Cheers,
Keean.
On 10 November 2010 22:07, Jonas Sicking jo...@sicking.cc
On Wed, Nov 10, 2010 at 2:43 PM, Getify get...@gmail.com wrote:
Ah okay. So that would never work. As things tagged with anonymous,
XMLHttpRequest without credentials, or AnonXMLHttpRequest would ignore
Set-Cookie headers.
First of all, a CORS xhr request could be made with credentials (since
From: Jonas Sicking [mailto:jo...@sicking.cc]
Sent: Wednesday, November 10, 2010 2:08 PM
On Wed, Nov 10, 2010 at 1:50 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Nov 10, 2010 at 1:43 PM, Pablo Castro
pablo.cas...@microsoft.com wrote:
From: public-webapps-requ...@w3.org
On Wed, Nov 10, 2010 at 2:05 PM, Chris Rogers crog...@google.com wrote:
After discussion with Anne and James, I retract my support for a new
constructor. I'm in favor of .responseType.
Specifically, .responseType would take values like (for legacy
treatment) / text / document / arraybuffer
On Wed, Nov 10, 2010 at 2:07 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Nov 10, 2010 at 1:50 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Nov 10, 2010 at 1:43 PM, Pablo Castro
pablo.cas...@microsoft.com wrote:
From: public-webapps-requ...@w3.org
On Wed, Nov 10, 2010 at 3:15 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Nov 10, 2010 at 2:07 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Nov 10, 2010 at 1:50 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Nov 10, 2010 at 1:43 PM, Pablo Castro
On 11/10/2010 03:00 PM, Tab Atkins Jr. wrote:
So you prefer that .responseType take a string value as opposed to an
integer enum value? Darin Fisher had the idea that introspection of the
supported values would be easier as an enum.
Yes, I think using an enum would be *extremely* verbose,
On 11/10/10 4:39 PM, Bjoern Hoehrmann wrote:
In most cases you do not need to store the bytes in order to get them
back, you can just apply the character encoding scheme used to decode
the bytes to the string and you'll have the original byte string, so
long as the character encoding scheme is
* Boris Zbarsky wrote:
On 11/10/10 4:39 PM, Bjoern Hoehrmann wrote:
In most cases you do not need to store the bytes in order to get them
back, you can just apply the character encoding scheme used to decode
the bytes to the string and you'll have the original byte string, so
long as the
I have a question regarding lastModifiedDate. The spec says that this
property returns an HTML5 valid date string. Per HTML 5 spec, a valid date
string consists of only year, month and day information. It does not contain
any time information. Do we really want this or what we want to return is a
Jian Li is right. I'm fixing this in the editor's draft.
- Original Message -
Good point; folks are going to want more precision than the day.
On Wed, Nov 10, 2010 at 9:03 PM, Jian Li jia...@chromium.org wrote:
I have a question regarding lastModifiedDate. The spec says that
this
30 matches
Mail list logo
