http://www.w3.org/Bugs/Public/show_bug.cgi?id=11389
Summary: IDBTransaction.READ_ONLY should probably be 0
Product: WebAppsWG
Version: unspecified
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority:
Ian - regarding the following specs that ended LC on June 30, do you
have some type of comment tracking document, like you did for XBL2
[XBL2-DoC]?
1. Server-sent Events
http://www.w3.org/TR/2009/WD-eventsource-20091222/
2. Web Storage
http://www.w3.org/TR/2009/WD-webstorage-20091222/
3. Web
The following tests were wrong, so I removed them from the VMMF test
suite. They were wrong because the UA is free to choose the most
suitable viewmode, and is under no obligation to respect the author's
wishes for a particular view mode.
test for=ta-vmmf id=ordered
Hi All,
How should ProgressEvents deal with compressed transfer encodings? The
problem is that the Content-Length header (if I understand things
correctly) contains the encoded number of bytes, so we don't have
access to the total number of bytes which will be exposed to the user
until it's all
On Tue, 23 Nov 2010 22:41:00 +0100, Jonas Sicking jo...@sicking.cc wrote:
How should ProgressEvents deal with compressed transfer encodings? The
problem is that the Content-Length header (if I understand things
correctly) contains the encoded number of bytes, so we don't have
access to the total
My recollection of the status of ISSUE-108 is that CORS was going to
provide functionality equivalent to that of UMP when the CORS
credentials flag is false. CORS was also also going to expand its
Security Considerations section to explain the Confused Deputy issues,
possibly by borrowing text
How about this way of looking at it
Goals
1) prevent programmer error
2) provide a good user experience (browser is responsive with lots of tabs)
The solution to #1 as currently proposed is to guarantee that
requestAnimationFrame will have it's callback called periodically, even if
it's not
On Wed, Nov 24, 2010 at 12:08 PM, Gregg Tavares (wrk) g...@google.comwrote:
requestAnimationFrame though is generally designed to be used for updating
a canvas (2d or 3d) which will likely be heavy both in terms of CPU usage
(drawing lots of lines/curves/images into the canvas) and in terms of
My recollection matches Tyler's. At one point I volunteered to work on
the Security Considerations section and did a draft, but sadly got
distracted by other things. I can attempt to dust that draft off and
try again if that is useful.
-- Dirk
On Tue, Nov 23, 2010 at 3:05 PM, Tyler Close
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11394
Summary: We should throw if continue() is called with a key =
the current position
Product: WebAppsWG
Version: unspecified
Platform: PC
OS/Version: All
Status:
* Anne van Kesteren wrote:
On Tue, 23 Nov 2010 22:41:00 +0100, Jonas Sicking jo...@sicking.cc wrote:
A) Set total to 0, and loaded to the number of decompressed bytes
downloaded so far
B) Set total to the contents of the Content-Length header and
loaded the number of compressed bytes
* Jonas Sicking wrote:
How should ProgressEvents deal with compressed transfer encodings? The
problem is that the Content-Length header (if I understand things
correctly) contains the encoded number of bytes, so we don't have
access to the total number of bytes which will be exposed to the user
* Robert O'Callahan wrote:
Couldn't is never an issue here. You can always use setTimeout as a
backstop to ensure that your end-of-animation code runs even if
requestAnimationFrame never fires a callback. My concern is that authors are
likely to forget to do this even if they need to, because
On 11/23/10 9:31 PM, Bjoern Hoehrmann wrote:
That is what the draft already requires, if by compressed Jonas means
you remove all transfer encodings but retain the content encodings
This is actually ambiguous, since the near-total lack of server and UA
support for Transfer-Encoding: gzip
* Jonas Sicking wrote:
other person: Hmm.. we might want to disable cross-site posting for
forms some day, so is it such a good idea that cors enables it?
me: If we do disable it for forms we'll just disable it for cors too.
So much content will break for forms that the cors breakage won't be
what
On Tue, Nov 23, 2010 at 7:36 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote:
* Jonas Sicking wrote:
other person: Hmm.. we might want to disable cross-site posting for
forms some day, so is it such a good idea that cors enables it?
me: If we do disable it for forms we'll just disable it for cors
* Jonas Sicking wrote:
On Tue, Nov 23, 2010 at 7:36 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote:
At the point where browser vendors actually disable cross site form
posts it won't break a lot of sites, since browser vendors are not in
the habit of making changes that break a lot of sites.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11396
Summary: Add a callback to IDBDatabaseSync.transaction
Product: WebAppsWG
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
On Tue, Nov 23, 2010 at 9:18 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote:
* Jonas Sicking wrote:
On Tue, Nov 23, 2010 at 7:36 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote:
At the point where browser vendors actually disable cross site form
posts it won't break a lot of sites, since browser
19 matches
Mail list logo
