[whatwg] Multiple file download
Currently there are implementations allowing multiple file upload without the need for flash or java applets. What doesn't seem to be there, unless a java applet is used (haven't come across one using flash) is the multiple file download. Even Google Docs uses a zip file to download multiple files. Was wondering if this could be made part of the standard. If something like resource packages http://limi.net/articles/resource-packages/ were used, the server would still be sending one file which could be heavily compressed, letting the UA to decompress and display as if a bunch of files had been downloaded separately. /J
Re: [whatwg] Offscreen canvas (or canvas for web workers).
On Tue, Feb 23, 2010 at 12:46 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Feb 22, 2010 at 4:34 PM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Feb 23, 2010 at 12:05 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Feb 22, 2010 at 3:43 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Feb 22, 2010 at 11:10 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Feb 22, 2010 at 11:13 AM, David Levin le...@google.com wrote: I've talked with some other folks on WebKit (Maciej and Oliver) about having a canvas that is available to workers. They suggested some nice modifications to make it an offscreen canvas, which may be used in the Document or in a Worker. What is the use case for this? It seems like in most cases you'll want to display something on screen to the user, and so the difference comes down to shipping drawing commands across the pipe, vs. shipping the pixel data. Sometimes the commands take up a lot more CPU power than shipping the pixels. Lets say you wanted to have a really rich map application that looked great, was highly interactive/fluid, but didn't use a lot of bandwidth. Rendering different parts of the screen on different workers seems like a legit use. I admit to not being a graphics expert, but I would imagine you have to do quite a lot of drawing before 1. Drawing on offscreen canvas 2. Cloning the pixel data in order to ship it to a different thread 3. Drawing the pixel data to the on-screen canvas Presumably a smart UA implementation could make 1 and 3 be nearly nothing (with copy on write and such) in many cases. Huh? I thought the whole point was that 1 was expensive, which was why you wanted to do it off the main thread. And 3 is what puts pixels on the screen so I don't see how you could do that without copying. You could possibly implement 3 using blitting, but that's still not nearly nothing. Possibly 2 is what you could get rid of using copy-on-write. gets to be cheaper than 1. Drawing to on-screen canvas. You're assuming only one core. The norm on the desktops and laptops these days is multiple cores. I did not assume that no. But it sounded like your use case was to rasterize off the main thread, get the pixels to the main thread, and then draw there. The last part (step 3 above) will definitely happen on the main thread no matter how many cores you have. Sorry, I didn't read clearly before sending. Yes, 1 would presumably be expensive and thus worth doing on a worker. Even on a single core machine, workers are great for long tasks since you needn't add breaks to your code via setTimeout so the UI can be updated (which doesn't always work perfectly anyway). 2 could be done with copy on write in many cases. 3 is just blitting which is generally a pretty fast operation. I've gotten a couple responses back on use cases. I'll admit that about half a simply resize/rotate. The others I've been told I cannot talk about publicly. I think my map tiles example is similar enough to a bunch of them though that you can get at least the conceptual idea. And my understanding is that in prototypes, it's been very hard to do the (computationally complex) rendering without making the UI go janky. There might be some more use cases that come up that I can generalize into a public form, in which case I'll do my best.
Re: [whatwg] Multiple file download
On Tue, 2010-02-23 at 10:10 +, Jose Fandos wrote: Currently there are implementations allowing multiple file upload without the need for flash or java applets. What doesn't seem to be there, unless a java applet is used (haven't come across one using flash) is the multiple file download. Even Google Docs uses a zip file to download multiple files. Was wondering if this could be made part of the standard. If something like resource packages were used, the server would still be sending one file which could be heavily compressed, letting the UA to decompress and display as if a bunch of files had been downloaded separately. /J Do any browsers support the resource packages link you gave? As for multiple file download in the manner you describe, that would require some pretty big changes to the http protocol as far as I can tell, as it is there that this sort of thing is handled. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] Offscreen canvas (or canvas for web workers).
On Mon, Feb 22, 2010 at 4:05 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Feb 22, 2010 at 3:43 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Feb 22, 2010 at 11:10 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Feb 22, 2010 at 11:13 AM, David Levin le...@google.com wrote: I've talked with some other folks on WebKit (Maciej and Oliver) about having a canvas that is available to workers. They suggested some nice modifications to make it an offscreen canvas, which may be used in the Document or in a Worker. What is the use case for this? It seems like in most cases you'll want to display something on screen to the user, and so the difference comes down to shipping drawing commands across the pipe, vs. shipping the pixel data. Sometimes the commands take up a lot more CPU power than shipping the pixels. Lets say you wanted to have a really rich map application that looked great, was highly interactive/fluid, but didn't use a lot of bandwidth. Rendering different parts of the screen on different workers seems like a legit use. I admit to not being a graphics expert, but I would imagine you have to do quite a lot of drawing before 1. Drawing on offscreen canvas 2. Cloning the pixel data in order to ship it to a different thread 3. Drawing the pixel data to the on-screen canvas The pixel copies are not as expensive as you might imagine. (You just described how rendering works in Chrome.) Step #1 can vastly dominate if drawing is complex. Imagine if it involved something as complicated and expensive as rendering a web page. Doing work that expensive on a background thread becomes imperative to maintaining good responsiveness of the main UI thread of the application, so the extra copies can be well worth the cost. -Darin gets to be cheaper than 1. Drawing to on-screen canvas. The other use case I can think of is doing image manipulation and then sending the result directly to the server, without ever displaying it to the user. However this is first of all not supported by the suggested API, and second I can't think of any image manipulation that you wouldn't want to display to the user except for scaling down a high resolution image. But that seems like a much simpler API than all of canvas. And again, not even this simple use case is supported by the current API. OK, so you solve this one problem. Then soon enough someone wants to do something more than just scale an image. So you you add another one off solution. Then another. Next thing you've essentially created canvas prime We've always started with use cases and then created APIs that fulfills those use cases, rather than come up with APIs and hope that that fulfills some future use case. That seems like a much wiser path here too. I'll note that there are a bunch of teams that want this behavior, though I can't remember exactly what for. But you're sure that it fulfills their requirements? ;-) At least some of it is simple image resizing type stuff. Most of it is related to doing image manipulation work that the app is probably going to need soon (but isn't on the screen yet...and that we don't want to slow the main thread for). Really, if you use picassa (or iPhoto or some other competitor) it really isn't hard to think of a lot of uses for this. Even for non-photo Apps (like Bespin) I could totally see it being worth it to them to do some rendering off the main loop. For many of these things you want to display the image to the user at the same time as the To be honest, I think the applications are largely self evident...especially if you think about taking rich desktop apps and making them web apps. So picassa and/or iPhoto uses off-main-thread *drawing* (not image scaling) today? Are you sure that you're negativity towards an offscreen canvas isn't simply being driven by implementation related worries? Quite certain. I can promise to for every API suggested, that if there are no use cases included, and no one else asks, I will ask what the use case is. / Jonas
Re: [whatwg] Offscreen canvas (or canvas for web workers).
On Tue, Feb 23, 2010 at 11:31 AM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Feb 23, 2010 at 12:46 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Feb 22, 2010 at 4:34 PM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Feb 23, 2010 at 12:05 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Feb 22, 2010 at 3:43 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Feb 22, 2010 at 11:10 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Feb 22, 2010 at 11:13 AM, David Levin le...@google.com wrote: I've talked with some other folks on WebKit (Maciej and Oliver) about having a canvas that is available to workers. They suggested some nice modifications to make it an offscreen canvas, which may be used in the Document or in a Worker. What is the use case for this? It seems like in most cases you'll want to display something on screen to the user, and so the difference comes down to shipping drawing commands across the pipe, vs. shipping the pixel data. Sometimes the commands take up a lot more CPU power than shipping the pixels. Lets say you wanted to have a really rich map application that looked great, was highly interactive/fluid, but didn't use a lot of bandwidth. Rendering different parts of the screen on different workers seems like a legit use. I admit to not being a graphics expert, but I would imagine you have to do quite a lot of drawing before 1. Drawing on offscreen canvas 2. Cloning the pixel data in order to ship it to a different thread 3. Drawing the pixel data to the on-screen canvas Presumably a smart UA implementation could make 1 and 3 be nearly nothing (with copy on write and such) in many cases. Huh? I thought the whole point was that 1 was expensive, which was why you wanted to do it off the main thread. And 3 is what puts pixels on the screen so I don't see how you could do that without copying. You could possibly implement 3 using blitting, but that's still not nearly nothing. Possibly 2 is what you could get rid of using copy-on-write. gets to be cheaper than 1. Drawing to on-screen canvas. You're assuming only one core. The norm on the desktops and laptops these days is multiple cores. I did not assume that no. But it sounded like your use case was to rasterize off the main thread, get the pixels to the main thread, and then draw there. The last part (step 3 above) will definitely happen on the main thread no matter how many cores you have. Sorry, I didn't read clearly before sending. Yes, 1 would presumably be expensive and thus worth doing on a worker. Even on a single core machine, workers are great for long tasks since you needn't add breaks to your code via setTimeout so the UI can be updated (which doesn't always work perfectly anyway). 2 could be done with copy on write in many cases. 3 is just blitting which is generally a pretty fast operation. I've gotten a couple responses back on use cases. I'll admit that about half a simply resize/rotate. The others I've been told I cannot talk about publicly. I think my map tiles example is similar enough to a bunch of them though that you can get at least the conceptual idea. And my understanding is that in prototypes, it's been very hard to do the (computationally complex) rendering without making the UI go janky. There might be some more use cases that come up that I can generalize into a public form, in which case I'll do my best. Note that doing rendering in a worker and then displaying it on the the main thread also gives you double buffering for no additional cost. This is something our teams are excited about as well.
Re: [whatwg] Multiple file download
On Tue, Feb 23, 2010 at 10:33 AM, Ashley Sheridan a...@ashleysheridan.co.ukwrote: On Tue, 2010-02-23 at 10:10 +, Jose Fandos wrote: Currently there are implementations allowing multiple file upload without the need for flash or java applets. What doesn't seem to be there, unless a java applet is used (haven't come across one using flash) is the multiple file download. Even Google Docs uses a zip file to download multiple files. Was wondering if this could be made part of the standard. If something like resource packages http://limi.net/articles/resource-packages/ were used, the server would still be sending one file which could be heavily compressed, letting the UA to decompress and display as if a bunch of files had been downloaded separately. /J Do any browsers support the resource packages link you gave? I don't know but don't think any browser does just yet. From the link I gave, it is just being specified. As for multiple file download in the manner you describe, that would require some pretty big changes to the http protocol as far as I can tell, as it is there that this sort of thing is handled. The resource packages specification is doing in my eyes exactly that. Allowing scripting to select files to put in a resource-type package and having the browser uncompress and save to disk (like a regular download) rather than processing them to render the page would allow this without any big changes, as long as resource packages makes it through. /J Thanks, Ash http://www.ashleysheridan.co.uk -- Jose Fandos CEO Andekan LLC 5727 Claremont Avenue Oakland, CA 94618 Phone: 415.366.7755 Fax: 415.373.3858 UK: +44 797 198 7757 www.andekan.com
Re: [whatwg] Multiple file download
On 2/23/10 5:10 AM, Jose Fandos wrote: What doesn't seem to be there, unless a java applet is used (haven't come across one using flash) is the multiple file download. Even Google Docs uses a zip file to download multiple files. What do you mean in terms of multiple file download? You can do this right now in two ways: 1) An archive file (your zip example) with the files in it. 2) A multipart response with the files as parts, each part having Content-Disposition: attachment. You can gzip this multipart response to get the compression behavior you want. -Boris
[whatwg] XSS safe templating
I'm working with EcmaScript TC39 trying to allow for experimentation with new content generation techniques in JavaScript. There's one missing piece which would let template language authors experiment with varying degrees of XSS-safety, and I was hoping that a change like the below might make it into HTML5. When user-code does document.write(value), myElement.innerHTML = value, etc. and the value is an object, currently it is coerced to a string by indirectly calling the toString method. I would like the toString method to be called with 'html ' + the current HTML 5 insertion mode to give structured template return values a chance to apply appropriate escaping schemes. For attribute sets, it would be nice to call toString with the argument 'attr ' + attribute name. This would be backwards compatible as toString implementations ignore parameters (modulo Number). To flesh out this proposal, what areas should I pay attention to? cheers, mike
Re: [whatwg] Multiple file download
On Tue, Feb 23, 2010 at 5:07 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 2/23/10 5:10 AM, Jose Fandos wrote: What doesn't seem to be there, unless a java applet is used (haven't come across one using flash) is the multiple file download. Even Google Docs uses a zip file to download multiple files. What do you mean in terms of multiple file download? Download 10 files as 10 separate files, without having to a) Okay the saving of each file to your drive independently b) Downloading them as a zip file that then needs to be uncompressed by the end user Imagine a list of files showing on a website (like google docs, or like you would have in a default ftp listing in firefox). Scripting would allow a selection of a number of these files and a download button would open a dialog on the UA to select the folder where the files will be copied to. You can do this right now in two ways: 1) An archive file (your zip example) with the files in it. This is b) which we have, agreed, but not what I meant by allowing multiple file download. It's allowing the download of just one file, the zip file. 2) A multipart response with the files as parts, each part having Content-Disposition: attachment. as far as I know, and I could be wrong, this would suffer from what I described in a), i.e. there would be a dialog propping up to accept each downloaded file. You can gzip this multipart response to get the compression behavior you want. I was suggesting the resource packages as a way to make use of compression/decompression. /J -Boris -- Jose Fandos CEO Andekan LLC 5727 Claremont Avenue Oakland, CA 94618 Phone: 415.366.7755 Fax: 415.373.3858 UK: +44 797 198 7757 www.andekan.com
Re: [whatwg] Multiple file download
On Tue, 2010-02-23 at 18:12 +, Jose Fandos wrote: On Tue, Feb 23, 2010 at 5:07 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 2/23/10 5:10 AM, Jose Fandos wrote: What doesn't seem to be there, unless a java applet is used (haven't come across one using flash) is the multiple file download. Even Google Docs uses a zip file to download multiple files. What do you mean in terms of multiple file download? Download 10 files as 10 separate files, without having to a) Okay the saving of each file to your drive independently b) Downloading them as a zip file that then needs to be uncompressed by the end user Imagine a list of files showing on a website (like google docs, or like you would have in a default ftp listing in firefox). Scripting would allow a selection of a number of these files and a download button would open a dialog on the UA to select the folder where the files will be copied to. You can do this right now in two ways: 1) An archive file (your zip example) with the files in it. This is b) which we have, agreed, but not what I meant by allowing multiple file download. It's allowing the download of just one file, the zip file. 2) A multipart response with the files as parts, each part having Content-Disposition: attachment. as far as I know, and I could be wrong, this would suffer from what I described in a), i.e. there would be a dialog propping up to accept each downloaded file. You can gzip this multipart response to get the compression behavior you want. I was suggesting the resource packages as a way to make use of compression/decompression. /J -Boris -- Jose Fandos CEO Andekan LLC 5727 Claremont Avenue Oakland, CA 94618 Phone: 415.366.7755 Fax: 415.373.3858 UK: +44 797 198 7757 www.andekan.com So how would you decide where each file goes? Would you just pick a directory and it chucks all the files in there? Also, the genius of archive files (zip, tar, rar) is that you can specify a path within the archive, so that a collection of files which requires a certain structure (a web page and its assets) are retained. Most operating systems have built-in features to read into these files as if they weren't archives at all. Windows can only do this for zip files, Linux can do it for most archive types, not sure about MacOS or other OS's. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] Multiple file download
On 23 February 2010 18:12, Jose Fandos iaminlon...@gmail.com wrote: 2) A multipart response with the files as parts, each part having Content-Disposition: attachment. as far as I know, and I could be wrong, this would suffer from what I described in a), i.e. there would be a dialog propping up to accept each downloaded file. So wouldn't the solution simply be to modify this behaviour? I'm sure one could write a patch for at least Firefox and Chrome to detect this situation and ask for a destination for all files...
Re: [whatwg] Multiple file download
On 2/23/10 1:12 PM, Jose Fandos wrote: 2) A multipart response with the files as parts, each part having Content-Disposition: attachment. as far as I know, and I could be wrong, this would suffer from what I described in a), i.e. there would be a dialog propping up to accept each downloaded file. Currently yes, but that seems like a UI issue, not a spec issue. Nothing _requires_ that behavior of UAs. I'd prefer just having a header in multipart responses to flag that all the files should probably be saved to the same location, or fixing UAs to only prompt once, to inventing yet another package format here. -Boris
Re: [whatwg] Multiple file download
What about 10K files to download? I don't like this idea. One could create a multiple file download page that could flood the client host. I would like to see the list of files I'm going to download before choosing save destination. For multiple download, I would prefer a dragdrop usability (just like for uploading). -- Diogo Resende drese...@thinkdigital.pt ThinkDigital On Tue, 2010-02-23 at 18:12 +, Jose Fandos wrote: On Tue, Feb 23, 2010 at 5:07 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 2/23/10 5:10 AM, Jose Fandos wrote: What doesn't seem to be there, unless a java applet is used (haven't come across one using flash) is the multiple file download. Even Google Docs uses a zip file to download multiple files. What do you mean in terms of multiple file download? Download 10 files as 10 separate files, without having to a) Okay the saving of each file to your drive independently b) Downloading them as a zip file that then needs to be uncompressed by the end user Imagine a list of files showing on a website (like google docs, or like you would have in a default ftp listing in firefox). Scripting would allow a selection of a number of these files and a download button would open a dialog on the UA to select the folder where the files will be copied to. You can do this right now in two ways: 1) An archive file (your zip example) with the files in it. This is b) which we have, agreed, but not what I meant by allowing multiple file download. It's allowing the download of just one file, the zip file. 2) A multipart response with the files as parts, each part having Content-Disposition: attachment. as far as I know, and I could be wrong, this would suffer from what I described in a), i.e. there would be a dialog propping up to accept each downloaded file. You can gzip this multipart response to get the compression behavior you want. I was suggesting the resource packages as a way to make use of compression/decompression. /J -Boris -- Jose Fandos CEO Andekan LLC 5727 Claremont Avenue Oakland, CA 94618 Phone: 415.366.7755 Fax: 415.373.3858 UK: +44 797 198 7757 www.andekan.com smime.p7s Description: S/MIME cryptographic signature
[whatwg] Web Workers: include simple example for shared workers
The Web Worker's first example of shared workers is quite involved and not
so easy to follow if you haven't dealt with shared workers before. For
someone wanting to experiment with shared workers, it's easier to grasp
how things work by doing something very basic first. It would be useful if
the spec had an example for this.
The example should include:
* How to create a shared worker.
* How to listen for messages from the worker. Note explicitly that the
listener is on the port -- not the worker object.
* If addEventListener('message',...) is used, note that start() needs to
be called.
* In the shared worker, show how to listen for connect events, how to
listen for messages on the port, how to post messages back. Note
explicitly that postMessage needs to be called on the 'connect' event's
ports[0]; not the 'message' event's ports[0].
* When all that is working, throw in another browsing context that
connects to the same worker.
Something like this:
step 1.
test.html
pre id=logLog:/pre
script
var worker = new SharedWorker('test.js');
var log = document.getElementById('log');
worker.port.onmessage = function(e) { // note: not worker.onmessage!
log.textContent += '\n' + e.data;
}
/script
test.js
onconnect = function(e) {
var port = e.ports[0];
port.postMessage('hello');
}
step 2.
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;
}, false);
worker.port.start(); // note: need this when using addEventListener
worker.port.postMessage('ping');
/script
test.js
onconnect = function(e) {
var port = e.ports[0];
port.postMessage('hello');
port.onmessage = function(e) {
port.postMessage('pong'); // not e.ports[0].postMessage!
}
}
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;
}, false);
worker.port.start();
worker.port.postMessage('ping');
/script
iframe src=other.html/iframe
other.html
pre id=logInner log:/pre
script
var worker = new SharedWorker('test.js');
var log = document.getElementById('log');
worker.port.onmessage = function(e) {
log.textContent += '\n' + e.data;
}
/script
test.js
onconnect = function(e) {
var port = e.ports[0];
port.postMessage('hello');
port.onmessage = function(e) {
port.postMessage('pong');
}
}
--
Simon Pieters
Opera Software
Re: [whatwg] Multiple file download
On Tue, Feb 23, 2010 at 10:45 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 2/23/10 1:12 PM, Jose Fandos wrote: 2) A multipart response with the files as parts, each part having Content-Disposition: attachment. as far as I know, and I could be wrong, this would suffer from what I described in a), i.e. there would be a dialog propping up to accept each downloaded file. Currently yes, but that seems like a UI issue, not a spec issue. Nothing _requires_ that behavior of UAs. I'd prefer just having a header in multipart responses to flag that all the files should probably be saved to the same location, or fixing UAs to only prompt once, to inventing yet another package format here. Indeed, if this can be fixed with no changes to specs that would be ideal. For a multipart response it seems like the UA is free to prompt in any way it sees fit. However one problem with a multipart response is that the UA doesn't know the number of files, or their types and sizes, until all files have been downloaded, right? If there was a way to indicate this information up front then I think we're good to go. / Jonas
Re: [whatwg] Multiple file download
On Tue, Feb 23, 2010 at 6:13 PM, Ashley Sheridan a...@ashleysheridan.co.ukwrote: On Tue, 2010-02-23 at 18:12 +, Jose Fandos wrote: On Tue, Feb 23, 2010 at 5:07 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 2/23/10 5:10 AM, Jose Fandos wrote: What doesn't seem to be there, unless a java applet is used (haven't come across one using flash) is the multiple file download. Even Google Docs uses a zip file to download multiple files. What do you mean in terms of multiple file download? Download 10 files as 10 separate files, without having to a) Okay the saving of each file to your drive independently b) Downloading them as a zip file that then needs to be uncompressed by the end user Imagine a list of files showing on a website (like google docs, or like you would have in a default ftp listing in firefox). Scripting would allow a selection of a number of these files and a download button would open a dialog on the UA to select the folder where the files will be copied to. You can do this right now in two ways: 1) An archive file (your zip example) with the files in it. This is b) which we have, agreed, but not what I meant by allowing multiple file download. It's allowing the download of just one file, the zip file. 2) A multipart response with the files as parts, each part having Content-Disposition: attachment. as far as I know, and I could be wrong, this would suffer from what I described in a), i.e. there would be a dialog propping up to accept each downloaded file. You can gzip this multipart response to get the compression behavior you want. I was suggesting the resource packages as a way to make use of compression/decompression. /J -Boris So how would you decide where each file goes? Would you just pick a directory and it chucks all the files in there? Yes, that would be the most common use. Allowing for choosing several different folders for different files would be left up to the UA. I don't thing the UA should bother with that, though; the waste of time to select a different folder for different sets of files negates the benefits of downloading 15 files in one go as 15 distinct files. Also, the genius of archive files (zip, tar, rar) is that you can specify a path within the archive, so that a collection of files which requires a certain structure (a web page and its assets) are retained. Agreed that's one benefit of archived files, but I'm looking for a more general use that's common within the desktop os yet it cannot be reproduced easily over a web app, namely copy a select set of file from here (website) to there (a folder in your desktop) without having to resort to decompression of archives. Most operating systems have built-in features to read into these files as if they weren't archives at all. Agreed, but it only goes so far. Mac OS doesn't, not natively, as far as I can see. I remember Windows did, but only for the file you were opening. If you opened a program to read a file from within the zip and that file depended on another file also in the zip, it wouldn't work. But that might have been fixed long ago. Still, this is a request I get often enough from non-technical people. We are covering this with a Java applet, but that brings its own set of issues. /J Windows can only do this for zip files, Linux can do it for most archive types, not sure about MacOS or other OS's. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] Multiple file download
On Tue, Feb 23, 2010 at 6:19 PM, Tim Hutt tdh...@gmail.com wrote: On 23 February 2010 18:12, Jose Fandos iaminlon...@gmail.com wrote: 2) A multipart response with the files as parts, each part having Content-Disposition: attachment. as far as I know, and I could be wrong, this would suffer from what I described in a), i.e. there would be a dialog propping up to accept each downloaded file. So wouldn't the solution simply be to modify this behaviour? I'm sure one could write a patch for at least Firefox and Chrome to detect this situation and ask for a destination for all files... It definitely would cover our needs, as long as everyone was using one of those browsers. Only benefit of it being part of the spec is that eventually it might be supported by every UA out there.
Re: [whatwg] Multiple file download
On Tue, Feb 23, 2010 at 6:45 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 2/23/10 1:12 PM, Jose Fandos wrote: 2) A multipart response with the files as parts, each part having Content-Disposition: attachment. as far as I know, and I could be wrong, this would suffer from what I described in a), i.e. there would be a dialog propping up to accept each downloaded file. Currently yes, but that seems like a UI issue, not a spec issue. Nothing _requires_ that behavior of UAs. I'd prefer just having a header in multipart responses to flag that all the files should probably be saved to the same location, or fixing UAs to only prompt once, to inventing yet another package format here. I shall file in a bug in bugzilla if there is none covering this already. But would it be too much of a stretch to use the same package format and almost the same process as the one defined for resource packages, in case that gets into the spec? Again, because this would eventually get taken up by everyone following the standard. /J -Boris
Re: [whatwg] Multiple file download
On Tue, Feb 23, 2010 at 9:11 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Feb 23, 2010 at 10:45 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 2/23/10 1:12 PM, Jose Fandos wrote: 2) A multipart response with the files as parts, each part having Content-Disposition: attachment. as far as I know, and I could be wrong, this would suffer from what I described in a), i.e. there would be a dialog propping up to accept each downloaded file. Currently yes, but that seems like a UI issue, not a spec issue. Nothing _requires_ that behavior of UAs. I'd prefer just having a header in multipart responses to flag that all the files should probably be saved to the same location, or fixing UAs to only prompt once, to inventing yet another package format here. Indeed, if this can be fixed with no changes to specs that would be ideal. For a multipart response it seems like the UA is free to prompt in any way it sees fit. However one problem with a multipart response is that the UA doesn't know the number of files, or their types and sizes, until all files have been downloaded, right? If there was a way to indicate this information up front then I think we're good to go. / Jonas Definitely a step in the right direction. I'll file a bug for Firefox... what about Chrome/Safari/Opera? /J
Re: [whatwg] Multiple file download
On Tue, Feb 23, 2010 at 1:27 PM, Jose Fandos iaminlon...@gmail.com wrote: On Tue, Feb 23, 2010 at 6:19 PM, Tim Hutt tdh...@gmail.com wrote: On 23 February 2010 18:12, Jose Fandos iaminlon...@gmail.com wrote: 2) A multipart response with the files as parts, each part having Content-Disposition: attachment. as far as I know, and I could be wrong, this would suffer from what I described in a), i.e. there would be a dialog propping up to accept each downloaded file. So wouldn't the solution simply be to modify this behaviour? I'm sure one could write a patch for at least Firefox and Chrome to detect this situation and ask for a destination for all files... It definitely would cover our needs, as long as everyone was using one of those browsers. Only benefit of it being part of the spec is that eventually it might be supported by every UA out there. As a browser developer, I can tell you that I'm not more likely to implement a certain UI just because it's spelled out in a spec. Browsers implement things that are useful for its users, not because a spec asks nicely. File bugs on browsers. Talk to websites to start using this. If you build it, they will come. / Jonas
Re: [whatwg] Multiple file download
On Tue, 2010-02-23 at 21:27 +, Jose Fandos wrote: On Tue, Feb 23, 2010 at 6:19 PM, Tim Hutt tdh...@gmail.com wrote: On 23 February 2010 18:12, Jose Fandos iaminlon...@gmail.com wrote: 2) A multipart response with the files as parts, each part having Content-Disposition: attachment. as far as I know, and I could be wrong, this would suffer from what I described in a), i.e. there would be a dialog propping up to accept each downloaded file. So wouldn't the solution simply be to modify this behaviour? I'm sure one could write a patch for at least Firefox and Chrome to detect this situation and ask for a destination for all files... It definitely would cover our needs, as long as everyone was using one of those browsers. Only benefit of it being part of the spec is that eventually it might be supported by every UA out there. I still don't think it's part of any html spec, but the http protocol. Just because a web browser will typically be the UA dealing with it does not necessarily mean it's something that should be dealt with in an html spec. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] Multiple file download
Boris Zbarsky wrote: or fixing UAs to only prompt once, to inventing yet another package format here. I'd go further: why not just give UAs an option to decompress a ZIP archive (or potentially other recognised archive format) to multiple files (or a folder containing them)? This would require no standards work and would be of general utility for all existing file downloads (I'd certainly be happy to shed a few clicks from the ZIP download-open-extract-delete shuffle). -- And Clover mailto:a...@doxdesk.com http://www.doxdesk.com/
Re: [whatwg] Multiple file download
On Wed, 2010-02-24 at 00:02 +0100, And Clover wrote: Boris Zbarsky wrote: or fixing UAs to only prompt once, to inventing yet another package format here. I'd go further: why not just give UAs an option to decompress a ZIP archive (or potentially other recognised archive format) to multiple files (or a folder containing them)? This would require no standards work and would be of general utility for all existing file downloads (I'd certainly be happy to shed a few clicks from the ZIP download-open-extract-delete shuffle). That's probably the smartest way to go about it. Won't break anything, just enhances the user experience that you'd normally get. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] Multiple file download
On Tue, Feb 23, 2010 at 9:51 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Feb 23, 2010 at 1:27 PM, Jose Fandos iaminlon...@gmail.com wrote: On Tue, Feb 23, 2010 at 6:19 PM, Tim Hutt tdh...@gmail.com wrote: On 23 February 2010 18:12, Jose Fandos iaminlon...@gmail.com wrote: 2) A multipart response with the files as parts, each part having Content-Disposition: attachment. as far as I know, and I could be wrong, this would suffer from what I described in a), i.e. there would be a dialog propping up to accept each downloaded file. So wouldn't the solution simply be to modify this behaviour? I'm sure one could write a patch for at least Firefox and Chrome to detect this situation and ask for a destination for all files... It definitely would cover our needs, as long as everyone was using one of those browsers. Only benefit of it being part of the spec is that eventually it might be supported by every UA out there. As a browser developer, I can tell you that I'm not more likely to implement a certain UI just because it's spelled out in a spec. Browsers implement things that are useful for its users, not because a spec asks nicely. I meant the implementation/re-use of a package format being part of the standard more than the UI. Though I'm happy to follow-up on the UI implementations. I had filed a bug for mozilla (bug 537669https://bugzilla.mozilla.org/show_bug.cgi?id=537669) on this at the beginning of the year. It stands unconfirmed. If anyone can confirm the bug, that would be swell. I'll attach a test case to the bugs to show the multiple dialogs currently showing. I'm submitting the bug at bugs.webkit.org as soon as I get the account ready. Already submitted bug report to Opera. /J File bugs on browsers. Talk to websites to start using this. If you build it, they will come. / Jonas
Re: [whatwg] Customize HTML5 forms placeholder style
On Mon, Feb 22, 2010 at 6:30 PM, Ashley Sheridan a...@ashleysheridan.co.uk wrote: I think it's perfectly reasonable if they decide to use colours that differ wildly from the 'norm'. They are used to setting the color value when they set the background-color (although not always the other way around) It's extremely common to mess that up. This would be even worse in some ways, since it would only be relevant for a small minority of elements (inputs with placeholders set). And because it would be so uncommon, when it *would* come up, normal authors would be unlikely to know the correct pseudo-class/element to fix it. So I do think it would be valuable to not require extra declarations from authors. On the other hand, the problem will only come up if the author uses placeholders *and* colors inputs, so its practical impact is limited. And of course the author will see it during even cursory testing, unlike relying on default background-color. So it's not really critical, but would be nice to have anyway.
Re: [whatwg] Multiple file download
On Feb 23, 2010, at 6:02 PM, And Clover wrote: Boris Zbarsky wrote: or fixing UAs to only prompt once, to inventing yet another package format here. I'd go further: why not just give UAs an option to decompress a ZIP archive (or potentially other recognised archive format) to multiple files (or a folder containing them)? Some UAs already have this feature. In Safari, if you have the 'Open safe files after downloading' option enabled (I believe it's enabled by default, though I usually leave it disabled because there have been a few exploits contained in supposedly safe files), it will unpack your ZIP or .tar.gz archives, and delete the archive leaving only the resulting folder. This would require no standards work and would be of general utility for all existing file downloads (I'd certainly be happy to shed a few clicks from the ZIP download-open-extract-delete shuffle). Yep, there's nothing stopping browsers from implementing this, and there are already browser that do it. It's just a matter of encouraging other browser vendors to follow suit. -- Brain
Re: [whatwg] Multiple file download
On Tue, 2010-02-23 at 22:50 -0500, Brian Campbell wrote: On Feb 23, 2010, at 6:02 PM, And Clover wrote: Boris Zbarsky wrote: or fixing UAs to only prompt once, to inventing yet another package format here. I'd go further: why not just give UAs an option to decompress a ZIP archive (or potentially other recognised archive format) to multiple files (or a folder containing them)? Some UAs already have this feature. In Safari, if you have the 'Open safe files after downloading' option enabled (I believe it's enabled by default, though I usually leave it disabled because there have been a few exploits contained in supposedly safe files), it will unpack your ZIP or .tar.gz archives, and delete the archive leaving only the resulting folder. This would require no standards work and would be of general utility for all existing file downloads (I'd certainly be happy to shed a few clicks from the ZIP download-open-extract-delete shuffle). Yep, there's nothing stopping browsers from implementing this, and there are already browser that do it. It's just a matter of encouraging other browser vendors to follow suit. -- Brain Ideally I guess then, the browsers would support .tar.gz files as these give much better compression than .zip. Unfortunately, that's probably unlikely to happen this decade with a certain browser made by a company that is known for trying to get developers to do things their way... Thanks, Ash http://www.ashleysheridan.co.uk
[whatwg] HTML Cookie API
The document.cookie API is kind of terrible. Web developers shouldn't have to parse a cookie-string or prepare a properly formated set-cookie-string. Here's a proposal for an HTML cookie API that isn't as terrible: https://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTRmdHFma21kMghl=en I'd like to propose we include this API in a future version of HTML. As always, feedback welcome. Adam
Re: [whatwg] HTML Cookie API
On Tue, Feb 23, 2010 at 8:56 PM, Adam Barth w...@adambarth.com wrote: The document.cookie API is kind of terrible. Web developers shouldn't have to parse a cookie-string or prepare a properly formated set-cookie-string. Here's a proposal for an HTML cookie API that isn't as terrible: https://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTRmdHFma21kMghl=en I'd like to propose we include this API in a future version of HTML. As always, feedback welcome. I really think the API should be asynchronous, as to avoid the mess that .localStorage currently is. / Jonas
Re: [whatwg] HTML Cookie API
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 document.cookie API is kind of terrible. Web developers shouldn't have to parse a cookie-string or prepare a properly formated set-cookie-string. Here's a proposal for an HTML cookie API that isn't as terrible: https://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTRmdHFma21kMghl=en I'd like to propose we include this API in a future version of HTML. As always, feedback welcome. I really think the API should be asynchronous, as to avoid the mess that .localStorage currently is. Done. Adam
Re: [whatwg] Offscreen canvas (or canvas for web workers).
On Feb 23, 2010, at 7:40 AM, Jeremy Orlow wrote: Note that doing rendering in a worker and then displaying it on the the main thread also gives you double buffering for no additional cost. This is something our teams are excited about as well. While I think the use cases presented for background thread image manipulation are valid, I'm confused about this claim: (A) canvas implementations do double-buffering anyway, to avoid drawing intermediate states in the middle of JS execution. (B) If you want triple-buffering (maybe you want to use multiple event loop cycles to draw the next frame), you don't need a Worker to do it. You can BTW some examples of shipping pixels being much less shipping drawing commands: - Raytracing a complex scene at high resolution. - Drawing a highly zoomed in high resolution portion of the Mandelbrot set. To be fair though, you could compute the pixels for those with just math, there is no need to have a graphics context type abstraction. Regards, Maciej
Re: [whatwg] Offscreen canvas (or canvas for web workers).
On Tue, Feb 23, 2010 at 9:57 PM, Maciej Stachowiak m...@apple.com wrote: - Raytracing a complex scene at high resolution. - Drawing a highly zoomed in high resolution portion of the Mandelbrot set. To be fair though, you could compute the pixels for those with just math, there is no need to have a graphics context type abstraction. http://people.mozilla.com/~sicking/webgl/ray.html http://people.mozilla.com/~sicking/webgl/juliaanim.html http://people.mozilla.com/~sicking/webgl/mandjulia.html Done and done, no need for workers ;-) / Jonas
Re: [whatwg] HTML Cookie API
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 document.cookie API is kind of terrible. Web developers shouldn't have to parse a cookie-string or prepare a properly formated set-cookie-string. Here's a proposal for an HTML cookie API that isn't as terrible: https://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTRmdHFma21kMghl=en I'd like to propose we include this API in a future version of HTML. As always, feedback welcome. I really think the API should be asynchronous, as to avoid the mess that .localStorage currently is. Done. The array-like object containing the Cookies for the document should be a read-only copy of a set of objects that represent all the applicable cookies at some point between the request and the response. This needs to be really clear and it needs to be clear what happens if a user, say, calls setCookie() in the middle of iterating through the array-like object (imho the iteration should be unaffected). It's probably best to specify the ordering of Cookies in this array-like object to match rfc2965's ordering rules so that users of the API don't have to implement this ordering themselves. Accessing cookies from script is inherently racy - there is no way to promise that the browser will or will not return a cookie being set by some HTTP response arriving at the same time as the getCookies() call. There's nothing really you can do about this but I think that this fact should be highlighted in the spec. If a U-A's privacy settings disallow script from accessing cookies, there should be some clear behavior. It looks like a U-A could make setCookie() a no-op and always invoke the getCookies() callback with an empty list now - should that be specified? - James Adam
Re: [whatwg] Offscreen canvas (or canvas for web workers).
On Tue, Feb 23, 2010 at 10:04 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Feb 23, 2010 at 9:57 PM, Maciej Stachowiak m...@apple.com wrote: - Raytracing a complex scene at high resolution. - Drawing a highly zoomed in high resolution portion of the Mandelbrot set. To be fair though, you could compute the pixels for those with just math, there is no need to have a graphics context type abstraction. http://people.mozilla.com/~sicking/webgl/ray.html http://people.mozilla.com/~sicking/webgl/juliaanim.html http://people.mozilla.com/~sicking/webgl/mandjulia.html Done and done, no need for workers ;-) (Updated to support recent webkit and chromium nightlies) / Jonas
