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 wrote:
> > I have a question regarding lastModifiedDate. The spec says that
> > this
> > property
Good point; folks are going to want more precision than the day.
On Wed, Nov 10, 2010 at 9:03 PM, Jian Li wrote:
> 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, m
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 "
* 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 t
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 bi
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, par
On Wed, Nov 10, 2010 at 3:15 PM, Tab Atkins Jr. wrote:
> On Wed, Nov 10, 2010 at 2:07 PM, Jonas Sicking wrote:
>> On Wed, Nov 10, 2010 at 1:50 PM, Tab Atkins Jr. wrote:
>>> On Wed, Nov 10, 2010 at 1:43 PM, Pablo Castro
>>> wrote:
From: public-webapps-requ...@w3.org [mailto:public-weba
On Wed, Nov 10, 2010 at 2:07 PM, Jonas Sicking wrote:
> On Wed, Nov 10, 2010 at 1:50 PM, Tab Atkins Jr. wrote:
>> On Wed, Nov 10, 2010 at 1:43 PM, Pablo Castro
>> 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 2:58 PM, Pablo Castro
wrote:
>
> 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.
>>> wrote:
>>> > On Wed, Nov 10, 2010 at 1:43 PM, Pablo Castro
>>> > wrote:
>>> >>
>>> >> Fro
On Wed, Nov 10, 2010 at 2:05 PM, Chris Rogers 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
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. wrote:
>> > On Wed, Nov 10, 2010 at 1:43 PM, Pablo Castro
>> > wrote:
>> >>
>> >> From: public-webapps-requ...@w3.org
>> >> [mailto:public-webapps-requ..
On Wed, Nov 10, 2010 at 2:43 PM, Getify 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
> they
>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 wrote:
> On Wed, N
> 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 que
> 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 docum
* 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, whi
On Wed, Nov 10, 2010 at 1:50 PM, Tab Atkins Jr. wrote:
> On Wed, Nov 10, 2010 at 1:43 PM, Pablo Castro
> 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 happ
>
>
> 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 .responseTex
On Wed, Nov 10, 2010 at 1:39 PM, Bjoern Hoehrmann 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 both repre
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
>> wrote:
>> >
>> > From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org]
>> > On Behalf Of bugzi...@jessica.w3.org
>> > Sent: Mon
On Wed, Nov 10, 2010 at 1:43 PM, Pablo Castro
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 the following
>>>
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 the following
>> keypath, the following value. (The generated key is 4):
>>
>> "f
* 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 synchronou
On Tue, Nov 9, 2010 at 12:03 PM, Tab Atkins Jr. wrote:
> On Tue, Nov 9, 2010 at 11:54 AM, Chris Rogers 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 potential
>> performance and com
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 wrote:
> Personally, I don't think new respo
On Wed, 10 Nov 2010 21:40:01 +0100, Bjoern Hoehrmann
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
any request witho
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 ou
* 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 w
On Wed, Nov 10, 2010 at 12:08 PM, Getify wrote:
> A discussion has been going on in W3C public-html about a proposed
> `rel=anonymous` feature that would suppress cookies, auth, referrer headers,
> etc. The purpose would be to use that rel attribute value on static
> resources to improve performan
?A discussion has been going on in W3C public-html about a proposed
`rel=anonymous` feature that would suppress cookies, auth, referrer headers,
etc. The purpose would be to use that rel attribute value on static resources
to improve performance, by cutting down on unnecessary headers being sent
On Wed, Nov 10, 2010 at 10:38 AM, Shawn Wilsher 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 Ev
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, IDBTransactio
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 wo
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 Tue, Nov 9, 2010 at 12:13 PM, viji wrote:
> Hello
>
> Here are some issues/clarifications on the p&c test suite
>
> 1. ta-uLHyIMvLwz/000 : dl.wgt
>
> The archive is not encrypted. The test description mentions that it is
> encrypted
Should be encrypted now. Password is 'test'.
> 2. i18n-lro
On Tue, 09 Nov 2010 21:03:22 +0100, Jonas Sicking wrote:
I still don't see the problem with the responseType. There's very
little difference in both BinaryHttpRequest and responseType is opt-in
mechanisms.
I am not a big fan of a new object either. It would require two new
objects, for one.
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/
http://www
37 matches
Mail list logo
