re: Proposal for sending multiple files via XMLHttpRequest.send()
I'd like to revive the "Proposal for sending multiple files via
XMLHttpRequest.send()" thread
started by Jian Li back in September.
As pointed out on that thread, sending a JS array of strings and File
references isn't going
to fly due to an array of strings already having meaning.
That thread concluded with Jonas Sicking saying:
> I definitely think that we need to add some way of sending a stream
> that is a concatenation of strings, binary data, and files, without
> requiring the files to be read.
What should this look like? Should there be a new global constructor for an
object that supports methods like appendText and appendFile? Like this:
var data = new UploadData;
data.appendText("foo");
data.appendFile(fileRef);
xhr.send(data);
I like the idea of creating a primitive that does not enforce any encoding.
Thoughts?
-Darin
New Progress events draft: 1.32
Hi folks, I committed a new draft[1] which incorporates my proposals for resolving ISSUE-105 (adding loadedItems and totalItems and trying to explain what happens when they are there. It also notes, but doesn't yet provide any solution for ISSUE-107 - I will think about it tomorrow. The changelog says that it is the intended basis for the LCWD but that's not true, at least until I find a resolution for 107... [1] http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html?rev=1.32 cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Use cases (appcache, etc) Re: Using progress events for other purposes
On Mon, 19 Oct 2009 20:13:23 +0200, Anne van Kesteren wrote: On Mon, 19 Oct 2009 18:30:31 +0200, Charles McCathieNevile wrote: On Sun, 18 Oct 2009 17:48:04 +0200, Charles McCathieNevile wrote: On Sun, 27 Sep 2009 21:04:04 +0200, Charles McCathieNevile I propose to add the attributes totalItems and loadedItems to preogress events, as a way of dealing with use cases like showing progress in downloading an application cache. This allows for firing progress events which have total/loaded values on individual items, by defining them as referring to the current item in the presence of the totalIems / loadedItems. Doe anyone have a use case or preference for making these a long long, or is a long enough? If only a subset of the attributes ends up being used, i.e. appcache is not going to dispatch progress events more often than one per file, I do not think this feature is worth it to be honest. Because for appcache total and loaded would always be 0 and for XMLHttpRequest totalItems and loadedITems would always be 0. Quite true. The hypothesis is that appcache may end up dealing with files where progress events *are* disaptched more than once per file, for example collecting a cache which has a 1MB video over a slow line. Are there any other cases worth considering? The other use case [1] that motivated this was a mail client downloading a number of distinct emails as objects, where some of them could be very large. My assumption is that these are real use cases, which is why I made the proposal (and bothered doing the thinking to try and spec it out). It's up to the group to decide, of course. [1] http://www.w3.org/mid/op.u0xi82ucwxe...@widsith.eng.oslo.osa cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
ISSUE-107 (multi-object end events): End state events in multi-object transactions [Progress Events]
ISSUE-107 (multi-object end events): End state events in multi-object transactions [Progress Events] http://www.w3.org/2008/webapps/track/issues/107 Raised by: Charles McCathieNevile On product: Progress Events Where a transaction has multiple objects (i.e. there is a loadedItems attribute present, and a value other than 1 for totalItems), should the end events (load/abort/error be fired for each object, or only on the completion of the entire transaction? I am assuming loadend should only fire at the end of the complete transaction (that might be a dumb assumption) but my current thinking is that it makes sense to fire a final event for each transaction (for example to learn what happened to each object, potentially allowing a request for only those that didn't come through cleanly the first time. For now this is left open in the editor's draft.
focus... Re: Touch and gestures events
On Mon, 19 Oct 2009 22:11:50 +0200, Olli Pettay wrote: On 10/19/09 8:56 PM, João Eiras wrote: ... Therefore they should be completely separate from any kind of mouse event feature. Obviously, the scroll and zoom events would need a target which would be the element with focus, Why the element with focus? Why not the element under cursor or something? (Similar to mouse wheel, which can be used to zoom, at least in Firefox) Well, there is an argument that focus and mouse navigation should be more closely tied in general - what you are hovering with the mouse is what you are looking at now, what I move to with the keyboard is what I am looking at now... cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: Touch and gestures events
Pan is scrolling for which browsers already fire events. The behavior for the scroll event would need to change though, so it would be fired before the event, and be cancelable. Well, scroll event indicates that something has been scrolled. So we shouldn't change its behavior. Pan is closer to wheel events. Probably changing the behaviour for scroll would not be the best idea. But then we could have a beforescroll event. Pan can easily be confused with scroll itself. Scale is the zooming feature which is also supported in many desktop browsers and mobile browsers, but lacks events. Rotation of the entire viewport is a UI feature, like when you tilt the device. These are all UI events, like focus and blur, and none of them are tied to gestures or mouse events. But web page should be able to capture "zoom" etc. For example Google maps might want to use it, if zooming happens above the map. So it is in a way related to mouse or whatever pointer. Yes, hence the part where I said "UI events". Therefore they should be completely separate from any kind of mouse event feature. Obviously, the scroll and zoom events would need a target which would be the element with focus, Why the element with focus? Why not the element under cursor or something? (Similar to mouse wheel, which can be used to zoom, at least in Firefox) I'm not going to write a detailed spec in each reply, you understood the context :) The event needs a target.
Re: solving the CPU usage issue for non-visible pages
I have a proposal for solving this here: http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/527d0cedb9b0df7f/57625c94cdf493bf The gist is very simple: 1) window.requestAnimationFrame(): Signals that an animation is in progress, and requests that the browser schedule a repaint of the window for the next animation frame, if the window is visible. 2) The browser fires a beforePaint event at the document root element (bubbling to document and window) any time it repaints the window. This event contains a 'displayTime' field containing a Javascript Date object representing the time at which this frame is likely to become visible to the user. Animation scripts should register an event handler that updates the DOM/CSS state to show that point in the animation. If the animation has not ended, the event handler should call window.requestAnimationFrame() again to ensure another frame will be scheduled in a timely manner. This gives the browser control over the frame rate, lets it suppress animation in non-visible windows, lets multiple animations play in synchrony, and should be easy to retrofit into code that's currently based on setInterval. I think it can also work well with architectures that do compositing in a dedicated thread or process. Rob -- "He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]
Re: Web Notifications, do we need a new spec?
Apologies for the delay, I've been spending the majority of my time completing the initial implementation for Chrome, but I've posted a draft version of a spec for notifications to http://sites.google.com/a/chromium.org/dev/developers/design-documents/desktop-notifications/api-specification I think that's a good starting point for formalizing it. This specification simplifies some of the notions of the widget spec (such as, is it necessary to bring the notifying context into view when a notification is generated?; i prefer they be passive). It is also more general in other areas (such as allowing more event handlers), so if there are specific requirements there we may need to come to consensus. -John 2009/9/7 Marcos Caceres > > > John Gregg wrote: > > Hi Marcos, > > > > I'm doing the implementation for Chromium so I'm pretty familiar with > > notifications. Although I'm fairly new to the process, I would be happy > > to volunteer to help, since I would definitely like to see a new > > notifications spec come together. > > Great! Basically, we just need a plain-text brain-dump from you about > how your implementation works and what the APIs. That should be > sufficient as a starting point to get the ball rolling. As I've got some > experience writing W3C specs, I'm happy to help co-edit. > > Before starting on an actual spec, the parts we need are: > > Requirements: > a simple list of what the requirements are. > (e.g., there must be a means to request the user's attention.) > > APIs: some IDL (or pseudo code) and a brief description of each of the > attribute or method. > > A description of how you envision notifications play with HTML5's > browsing contexts/origin. > > You might also look at what we originally had in the widget spec (search > for "The showNotification() Method" and "The getAttention() Method"): > > > http://dev.w3.org/cvsweb/~checkout~/2006/waf/widgets-api/Overview.src.html?rev=1.87&content-type=text/html;%20charset=iso-8859-1 > > showNotification() was based on some old HTML5 text, which was removed > about a year ago. Anyway, please let us know if you need anything else, > and we look forward your input! :D > > Kind regards, > Marcos >
Re: solving the CPU usage issue for non-visible pages
FYI, the original WhatWG thread: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-October/thread.html#23625 On Mon, Oct 19, 2009 at 1:51 PM, Gregg Tavares wrote: > I posted something about this in the whatwg list and was told to bring it > here. > > Currently, AFAIK, the only way to do animation in HTML5 + JavaScript is > using setInterval. That's great but it has the problem that even when the > window is minimized or the page is not the front tab, JavaScript has no way > to know to stop animating. So, for a CPU heavy animation using canvas 2d or > canvas 3d, even a hidden tab uses lots of CPU. Of course the browser does > not copy the bits from the canvas to the window but JavaScript is still > drawing hundreds of thousands of pixels to the canvas's internal image > buffer through canvas commands. > > To see an example run this sample in any browser > > http://mrdoob.com/projects/chromeexperiments/depth_of_field/ > > Minimize the window or switch to another tab and notice that it's still > taking up a bunch of CPU time. > > Conversely, look at this flash page. > > http://www.alissadean.com/ > > While it might look simple there is actually a lot of CPU based pixel work > required to composite the buttons with alpha over the scrolling clouds with > alpha over the background. > > Minimize that window or switch to another tab and unlike HTML5 + > JavaScript, flash has no problem knowning that it no longer needs to render. > > There are probably other possible solutions to this problem but it seems > like the easiest would be either > > *) adding an option to window.setInterval or only callback if the window is > visible > > *) adding window.setIntervalIfVisible (same as the previous option really) > > A possibly better solution would be > > *) element.setIntervalIfVisible > > Which would only call the callback if that particular element is visible. > > It seems like this will be come an issue as more and more HMTL5 pages start > using canvas to do stuff they would have been doing in flash like ads or > games. Without a solution those ads and games will continue to eat CPU even > when not visible which will make the user experience very poor. > > There may be other solutions. The advantage to this solution is it requires > almost no changes to logic of current animating applications. > > Some have suggested the UA can solve this but I don't see how a UA can know > when JavaScript should and should not run. For example chat and mail > applications run using setInterval even when not visible so just stopping > non-visible pages from running at all is not an option. > > Another suggested solution is for pages to default to only be processed > when visible and requiring the page to somehow notify the UA it needs > processing even when not-visible. This could break some existing apps but > they would likely be updated immediately. This solution might lessen the > probability of resource hogging pages in the future as > HTML5+JavaScript+canvas ads, games and other apps become more common since > the default would be for them not to hog the CPU when not visible. > > -gregg > > > >
solving the CPU usage issue for non-visible pages
I posted something about this in the whatwg list and was told to bring it here. Currently, AFAIK, the only way to do animation in HTML5 + JavaScript is using setInterval. That's great but it has the problem that even when the window is minimized or the page is not the front tab, JavaScript has no way to know to stop animating. So, for a CPU heavy animation using canvas 2d or canvas 3d, even a hidden tab uses lots of CPU. Of course the browser does not copy the bits from the canvas to the window but JavaScript is still drawing hundreds of thousands of pixels to the canvas's internal image buffer through canvas commands. To see an example run this sample in any browser http://mrdoob.com/projects/chromeexperiments/depth_of_field/ Minimize the window or switch to another tab and notice that it's still taking up a bunch of CPU time. Conversely, look at this flash page. http://www.alissadean.com/ While it might look simple there is actually a lot of CPU based pixel work required to composite the buttons with alpha over the scrolling clouds with alpha over the background. Minimize that window or switch to another tab and unlike HTML5 + JavaScript, flash has no problem knowning that it no longer needs to render. There are probably other possible solutions to this problem but it seems like the easiest would be either *) adding an option to window.setInterval or only callback if the window is visible *) adding window.setIntervalIfVisible (same as the previous option really) A possibly better solution would be *) element.setIntervalIfVisible Which would only call the callback if that particular element is visible. It seems like this will be come an issue as more and more HMTL5 pages start using canvas to do stuff they would have been doing in flash like ads or games. Without a solution those ads and games will continue to eat CPU even when not visible which will make the user experience very poor. There may be other solutions. The advantage to this solution is it requires almost no changes to logic of current animating applications. Some have suggested the UA can solve this but I don't see how a UA can know when JavaScript should and should not run. For example chat and mail applications run using setInterval even when not visible so just stopping non-visible pages from running at all is not an option. Another suggested solution is for pages to default to only be processed when visible and requiring the page to somehow notify the UA it needs processing even when not-visible. This could break some existing apps but they would likely be updated immediately. This solution might lessen the probability of resource hogging pages in the future as HTML5+JavaScript+canvas ads, games and other apps become more common since the default would be for them not to hog the CPU when not visible. -gregg
Re: Touch and gestures events
On 10/19/09 8:56 PM, João Eiras wrote: > to manipulate the objects you have on your device/OS. Pan is scrolling for which browsers already fire events. The behavior for the scroll event would need to change though, so it would be fired before the event, and be cancelable. Well, scroll event indicates that something has been scrolled. So we shouldn't change its behavior. Pan is closer to wheel events. Scale is the zooming feature which is also supported in many desktop browsers and mobile browsers, but lacks events. Rotation of the entire viewport is a UI feature, like when you tilt the device. These are all UI events, like focus and blur, and none of them are tied to gestures or mouse events. But web page should be able to capture "zoom" etc. For example Google maps might want to use it, if zooming happens above the map. So it is in a way related to mouse or whatever pointer. Therefore they should be completely separate from any kind of mouse event feature. Obviously, the scroll and zoom events would need a target which would be the element with focus, Why the element with focus? Why not the element under cursor or something? (Similar to mouse wheel, which can be used to zoom, at least in Firefox) -Olli
Re: [widgets] Step 5 - allowing private use lang tags ; ISSUE-93
On Oct 19, 2009, at 3:29 PM, ext Marcos Caceres wrote: In Step 5 [1], the spec reads: "If this range begins with the subtag "i", "x", or the range is marked as "deprecated" in the IANA Language Subtag Registry, skip all the steps in this algorithm below, and move onto the next range." I believe that, at least, we should allow "x" (as in "x-secret-lang"). The user agent is going to ignore sub-tags it does not know anyway. Proposed change: [[ "If this range begins with the subtag "i" or the range is marked as "deprecated" in the IANA Language Subtag Registry, skip all the steps in this algorithm below, and move onto the next range." ]] All - Marcos just clarified in IRC his proposal above is intended to close Issue-93 [1]. If anyone objects to this proposal, please respond by Oct 21 at the latest. -Regards, Art Barstow [1] http://www.w3.org/2008/webapps/track/issues/93
[widgets] Step 5 - allowing private use lang tags
In Step 5 [1], the spec reads: "If this range begins with the subtag "i", "x", or the range is marked as "deprecated" in the IANA Language Subtag Registry, skip all the steps in this algorithm below, and move onto the next range." I believe that, at least, we should allow "x" (as in "x-secret-lang"). The user agent is going to ignore sub-tags it does not know anyway. Proposed change: [[ "If this range begins with the subtag "i" or the range is marked as "deprecated" in the IANA Language Subtag Registry, skip all the steps in this algorithm below, and move onto the next range." ]] [1] http://dev.w3.org/2006/waf/widgets/Overview_TSE.html#step-5--derive-the-user-agents-locale -- Marcos Caceres http://datadriven.com.au
Re: Using progress events for other purposes
On Mon, 19 Oct 2009 18:30:31 +0200, Charles McCathieNevile wrote: On Sun, 18 Oct 2009 17:48:04 +0200, Charles McCathieNevile wrote: On Sun, 27 Sep 2009 21:04:04 +0200, Charles McCathieNevile I propose to add the attributes totalItems and loadedItems to preogress events, as a way of dealing with use cases like showing progress in downloading an application cache. This allows for firing progress events which have total/loaded values on individual items, by defining them as referring to the current item in the presence of the totalIems / loadedItems. Doe anyone have a use case or preference for making these a long long, or is a long enough? If only a subset of the attributes ends up being used, i.e. appcache is not going to dispatch progress events more often than one per file, I do not think this feature is worth it to be honest. Because for appcache total and loaded would always be 0 and for XMLHttpRequest totalItems and loadedITems would always be 0. Are there any other cases worth considering? -- Anne van Kesteren http://annevankesteren.nl/
Re: Touch and gestures events
We seem to come from different angles, and our objective may not the same as yours. This is not an official statement, but I could formulate our objective like this: "How do I enable richer web applications in a touch-aware browser while still retaining the possibility to interact with existing (mouse-aware) web applications." We all agree to that, but we disagree how to get there. A touch events API would be something completely new that would have any kind of backwards compatibility with existing content, meaning, one would need to code for the new API and older ones, and would have touch device bias. This means duplicate effort for everybody: spec writers, implementors, web authors. The most important is the possibility to track multiple touches individually, and above I have been trying to communicate the problems in just adding that to the existing mouse events. Second, touch-specific parameters are missing. Such include the pressure and bounding box of the touch. But do we need a new API and event model for this ? Can't this be solved already in mouse events ? Can't mouse events have the streamId (which would reference a pointing device), a pressure attribute and the geometry of the pointing device ? Currently, the mouse events API only supports single pixel pointing devices, but adding finger support would just require for all the coordinate properties of the event object to be means, and have the geometry somewhere globally accessible. Again, we don't need a completely new API and events model for this. Third, an input device independent way to do basic manipulation (pan/scale/rotate) to objects. It is well possible to implement just raw touch events, and do the gesture recognition in JavaScript, but then the actual gestures would follow the web site style, instead of the style introduced by operating system, and if your input device doesn't support multi-touch, it simply doesn't work on web content, no matter how clever way to manipulate the objects you have on your device/OS. Pan is scrolling for which browsers already fire events. The behavior for the scroll event would need to change though, so it would be fired before the event, and be cancelable. Scale is the zooming feature which is also supported in many desktop browsers and mobile browsers, but lacks events. Rotation of the entire viewport is a UI feature, like when you tilt the device. These are all UI events, like focus and blur, and none of them are tied to gestures or mouse events. Therefore they should be completely separate from any kind of mouse event feature. Obviously, the scroll and zoom events would need a target which would be the element with focus, but then, element can gain focus not only by using some pointing device. -- João Eiras Core Developer, Opera Software ASA, http://www.opera.com/
Re: Using progress events for other purposes
On Sun, 18 Oct 2009 17:48:04 +0200, Charles McCathieNevile wrote: On Sun, 27 Sep 2009 21:04:04 +0200, Charles McCathieNevile I propose to add the attributes totalItems and loadedItems to preogress events, as a way of dealing with use cases like showing progress in downloading an application cache. This allows for firing progress events which have total/loaded values on individual items, by defining them as referring to the current item in the presence of the totalIems / loadedItems. Doe anyone have a use case or preference for making these a long long, or is a long enough? cheers I have raised ISSUE-105 for this question. chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: Using progress events for other purposes
On Mon, 19 Oct 2009 11:38:27 +0200, Ian Hickson wrote: On Mon, 19 Oct 2009, Simon Pieters wrote: On Mon, 19 Oct 2009 10:24:37 +0200, Ian Hickson wrote: > > > > > > So in a hypothetical system that gives progress for multiple large > > > files in a row, you can't have a case where some of the files have > > > unknown sizes? > > > > Yes, you can. > > How? If I understand Chaals' proposal correctly, you'd set lengthComputable to false, loaded to the number of bytes having been downloaded for the current file, total to 0, loadedItems to the number of files that have finished, and totalItems to the total number of files. Chaals said "IFF they have lengthComputable true then the loaded and total refer to the particular item", which seems to contradict the above. If we just say that those attributes are meaningless in events that don't have file data, that works, but then the "IFF" condition isn't needed. Right. Turns out Simon was better at parsing what I *meant* than I was at expressing it. But as I have it in my head, we do need to say what the original attributes mean if there are loadedItems or totalItems (which is that they refer to the current item rather than e.g. the overall transaction set). That idea is of course is open to question. tracker, this is ISSUE-105 cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: Using progress events for other purposes
On Mon, 19 Oct 2009, Simon Pieters wrote: > On Mon, 19 Oct 2009 10:24:37 +0200, Ian Hickson wrote: > > > > > > > > So in a hypothetical system that gives progress for multiple large > > > > files in a row, you can't have a case where some of the files have > > > > unknown sizes? > > > > > > Yes, you can. > > > > How? > > If I understand Chaals' proposal correctly, you'd set lengthComputable > to false, loaded to the number of bytes having been downloaded for the > current file, total to 0, loadedItems to the number of files that have > finished, and totalItems to the total number of files. Chaals said "IFF they have lengthComputable true then the loaded and total refer to the particular item", which seems to contradict the above. If we just say that those attributes are meaningless in events that don't have file data, that works, but then the "IFF" condition isn't needed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Using progress events for other purposes
On Mon, 19 Oct 2009 10:24:37 +0200, Ian Hickson wrote: > So in a hypothetical system that gives progress for multiple large > files in a row, you can't have a case where some of the files have > unknown sizes? Yes, you can. How? If I understand Chaals' proposal correctly, you'd set lengthComputable to false, loaded to the number of bytes having been downloaded for the current file, total to 0, loadedItems to the number of files that have finished, and totalItems to the total number of files. -- Simon Pieters Opera Software
Re: Using progress events for other purposes
On Mon, 19 Oct 2009, Charles McCathieNevile wrote: > On Mon, 19 Oct 2009 06:43:18 +0200, Ian Hickson wrote: > > On Mon, 19 Oct 2009, Charles McCathieNevile wrote: > > > > > > OK, I'll work on it to try and get an editor's draft out tomorrow. > > > My rough idea is that you can send an event which has > > > lengthComputable false and totalItems / loadedItems, and IFF they > > > have lengthComputable true then the loaded and total refer to the > > > particular item - (does itemCount start from zero or one?) > > > > So in a hypothetical system that gives progress for multiple large > > files in a row, you can't have a case where some of the files have > > unknown sizes? > > Yes, you can. How? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
