On Tue, 23 Feb 2010 21:36:15 +0100, Simon Pieters sim...@opera.com wrote:
step 3.
test.html
pre id=logLog:/pre
script
var worker = new SharedWorker('test.js');
var log = document.getElementById('log');
worker.port.addEventListener('message', function(e) {
log.textContent += '\n' + e.data;
On Wed, 2010-02-24 at 11:21 -0800, Darin Fisher wrote:
For reference, reading document.cookie has measurable performance cost
in Chromium since the cookie jar lives in a process separate from the
process running JavaScript. We could have minimized this cost by
caching the cookies locally, but
Hello,
As a follow up to my paper advocating HTTP authentication over
cookies [1], I've built a simple sample application which demonstrates
how a combination of XMLHttpRequest and response code tricks can be
used to achieve form-based login, logout, and authenticated password
changes in the
On Thu, Feb 25, 2010 at 6:54 AM, Diogo Resende drese...@thinkdigital.ptwrote:
On Wed, 2010-02-24 at 11:21 -0800, Darin Fisher wrote:
For reference, reading document.cookie has measurable performance cost
in Chromium since the cookie jar lives in a process separate from the
process running
On Thu, 25 Feb 2010 18:58:37 +0100, Drew Wilson atwil...@google.com
wrote:
BTW, I think it's valuable to point out in the example that
MessageEvent.target == the port that received the message (so we don't
need
to use a closure as in the example below - just use
Hi All;
I'd like to know if there's room or any work has been done to set aside a
standard for an extended set of pointer-device events.
With touch screens and touch sensitivity becoming quite main-stream,
I'd like to see this popular functionality supported by the HTML 5 standard.
We see, in
On Tue, Feb 23, 2010 at 10:48 PM, James Robinson jam...@google.com wrote:
On Tue, Feb 23, 2010 at 9:21 PM, Adam Barth w...@adambarth.com wrote:
On Tue, Feb 23, 2010 at 9:15 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Feb 23, 2010 at 8:56 PM, Adam Barth w...@adambarth.com wrote:
The
This is a timely call for interest.
Additionally I would like to sollicit thoughts on the ideal level of
abstraction such event API's should provide.
Some random examples for illustration.
Low level: TouchDown(...) onTouchMove() onTouchUp() with each reporting and
tracking pressure and
On Tue, Feb 23, 2010 at 11:03 PM, Ashley Sheridan
a...@ashleysheridan.co.uk wrote:
Ideally I guess then, the browsers would support .tar.gz files as these give
much better compression than .zip.
ZIP and gzip give comparable compression, in my experience. I just
applied both to a random 3.5M
On Thu, 2010-02-25 at 19:13 -0500, Aryeh Gregor wrote:
On Tue, Feb 23, 2010 at 11:03 PM, Ashley Sheridan
a...@ashleysheridan.co.uk wrote:
Ideally I guess then, the browsers would support .tar.gz files as these
give much better compression than .zip.
ZIP and gzip give comparable
gzip and zip both use the same algorithm which is called DEFLATE. For a
single file they will give exactly the same results. tar.gz has a slight
advantage for multiple files because it treats them as one big file. That's
called 'solid compression'. However it does mean that in order to do
anything
On Fri, Feb 26, 2010 at 12:57 AM, Tim Hutt tdh...@gmail.com wrote:
gzip and zip both use the same algorithm which is called DEFLATE. For a
single file they will give exactly the same results. tar.gz has a slight
advantage for multiple files because it treats them as one big file. That's
On Thu, 25 Feb 2010 16:00:37 -, Timothy D. Morgan
tmor...@vsecurity.com wrote:
As a follow up to my paper advocating HTTP authentication over
cookies [1], I've built a simple sample application which demonstrates
how a combination of XMLHttpRequest and response code tricks can be
used to
Hi,
Right now, in the spec 2.7.5 Safe passing of structured data, it says
If input is another native object type (e.g. Error)
Return the null value.
but if we want to debug workers, it's more convenient to be able to
pass the error directly rather than
postMessage({name: err.name, message:
14 matches
Mail list logo