Re: [XHR] request error distinction: abort and error
On a general note, if window.stop() is invoked is not appropriate language. window.stop() could set some flag for XMLHttpRequest to look at, or have some other kind of connection, but implicit connections are bad. We should remove those when we encounter them. On Sat, Aug 17, 2013 at 1:48 AM, Jonas Sicking jo...@sicking.cc wrote: I come to the opposite conclusion. If the user stops a request then we should assume that the user wanted to. We shouldn't assume that users are erratic and don't know what they are doing. Given the UI for that (pressing Esc, right?) I would expect it to be more accidental. So based on the knowledge that browsers generally don't have UI for aborting XHRs, I would draw the conclusion that if the user did cause an abort, that that was *not* accidental but rather intentional. Interesting. -- http://annevankesteren.nl/
Re: [XHR] Event firing order. XMLHttpRequestUpload then XMLHttpRequest or reverse
On Thu, Aug 1, 2013 at 6:13 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Jul 30, 2013 at 10:25 AM, Takeshi Yoshino tyosh...@google.com wrote: Change on 2010/09/13 http://dev.w3.org/cvsweb/2006/webapi/XMLHttpRequest-2/Overview.src.html.diff?r1=1.138;r2=1.139;f=h reversed the order of event firing for request error algorithm and send() method to XHRUpload-then-XHR. send() (only loadstart event) and abort() method are still specified to fire events in XHR-then-XHRUpload order. Is this intentional or we should make them consistent? We should make them consistent in some manner. Firing on the main object last makes sense to me. It also makes some amount of conceptual sense to do the reverse for when the fetching starts, but I feel less strongly about that. Anyone opinions on this? Would be good to sort out and I don't really care one way or another. -- http://annevankesteren.nl/
[announce] Test the Web Forward: Shenzhen China 9 November 2013
If you are going to Shenzhen in November for TPAC, please note there is a Test the Web Forward event on Saturday November 9: [[ http://lists.w3.org/Archives/Public/public-testtwf/2013Aug/.html Now that we've wrapped up the Shanghai event, we've kicked off the planning for our next event. Because we love China so much, we're heading back! This time we'll be in Shenzhen and for the first time, Test the Web Forward will be part of of the W3C's annual TPAC conference [3]. If you're a W3C working group member planning to be at TPAC and you'd like to come and offer your expertise on your favorite spec, please let us know! Contact Rebecca Hauck at rha...@adobe.com. If you're unable to attend TPAC but would like suggest specs or areas that need tests, we'd also love your input. You can contact Rebecca directly or if you'd like to start a group discussion, please use our new TestTWF event planning mailing list - see more info on this new list below. [3] http://www.w3.org/2013/11/TPAC/ ]] WebApps will meet in Shenzhen November 11-12 http://www.w3.org/wiki/Webapps/November2013Meeting. Please note some people may need a visa to enter China http://www.w3.org/2013/11/TPAC/#Registration. -AB
Re: Extending createObjectUrl to MediaStream?
On 2013-08-28 17:48, Dominique Hazael-Massieux wrote: Hi WebApps WG, The Media Capture Task Force (responsible for specs that deal with MediaStream objects [1]) has been considering whether one should be able to assign a MediaStream to video and audio elements via an URL obtained via createObjectURL or not, and is seeking feedback on the question. More precisely: A. we define a new srcObject attribute on HTMLMediaElement objects that can take directly a MediaStream object and make it playable video.srcObject = mediastream; B. the spec also supports assigning a MediaStream via the src attribute, via an URL obtained through createObjectURL: video.src = URL.createObjectURL(mediastream); While there are ongoing discussions on how to spec B properly [2] (which will require coordination with the WebApps Working Group), we are first and foremost wondering if that option is needed at all. We are thus looking for input on the use cases for createObjectURL as used for the File API, and whether these use cases would also apply to our MediaStream case. In general, is there a need for any object readable by media elements to support an URL-based approach for consistency with the rest of the platform? One need I can see is when you want to display the video in another window. Let's say you want to have the video in a popout window - something I think we should definitely support - handing that window the URL (using postMessage) for use by its video element is a very convenient way to support this use-case. This works in Chrome today. But, an alternative could perhaps be to make MediaStream a transferable (which means that the MediaStream object could be sent over using postMessage IIUC). Thanks! Dom for capture-ACTION-23 1. http://dev.w3.org/2011/webrtc/editor/getusermedia.html 2. https://www.w3.org/Bugs/Public/show_bug.cgi?id=19594
[Bug 23102] New: Reset response entity bodies
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23102 Bug ID: 23102 Summary: Reset response entity bodies Classification: Unclassified Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: XHR Assignee: ann...@annevk.nl Reporter: ann...@annevk.nl QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org All response entity body types need to be reset where response entity body is reset as otherwise they might already have a value. -- You are receiving this mail because: You are on the CC list for the bug.
Re: [XHR] request error distinction: abort and error
On Aug 30, 2013 4:05 AM, Anne van Kesteren ann...@annevk.nl wrote: On a general note, if window.stop() is invoked is not appropriate language. window.stop() could set some flag for XMLHttpRequest to look at, or have some other kind of connection, but implicit connections are bad. We should remove those when we encounter them. Why? I agree that it can be hard to define order of externally visible effects, such as events, if there are any. However from a readability point of view indirection through state flags just makes the spec harder to read. So I don't see why removing such a pattern would be a goal in and of itself. On Sat, Aug 17, 2013 at 1:48 AM, Jonas Sicking jo...@sicking.cc wrote: I come to the opposite conclusion. If the user stops a request then we should assume that the user wanted to. We shouldn't assume that users are erratic and don't know what they are doing. Given the UI for that (pressing Esc, right?) I would expect it to be more accidental. No, pressing escape does not cancel requests in updated browsers. / Jonas
Re: [XHR] request error distinction: abort and error
On Fri, Aug 30, 2013 at 7:45 PM, Jonas Sicking jo...@sicking.cc wrote: Why? I agree that it can be hard to define order of externally visible effects, such as events, if there are any. However from a readability point of view indirection through state flags just makes the spec harder to read. So I don't see why removing such a pattern would be a goal in and of itself. Because often such a function would do other things and then the order of things is no longer deterministically defined. This is especially true for these kind of asynchronous operations. E.g. currently window.stop() invokes a abort Document operation which cancels all fetch algorithms running for that Document, which probably includes the fetch of XMLHttpRequest, although that is not really well defined at the moment, and also would not cause abort to happen (cancel just results in a network error). -- http://annevankesteren.nl/
[Bug 23106] New: Spec should treat content type as an opaque string
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23106 Bug ID: 23106 Summary: Spec should treat content type as an opaque string Classification: Unclassified Product: WebAppsWG Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: File API Assignee: a...@mozilla.com Reporter: ms2...@gmail.com QA Contact: public-webapps-bugzi...@w3.org CC: public-webapps@w3.org Bug 18521, bug 18523, bug 18528 and bug 18529 claim: We've decided to treat type as an opaque string. However, the Blob constructor [1] and the slice method [2] still lower-case their argument and limit it to the U+0020-U+007E range. This seems inconsistent. [1] http://dev.w3.org/2006/webapi/FileAPI/#constructorBlob [2] http://dev.w3.org/2006/webapi/FileAPI/#dfn-slice -- You are receiving this mail because: You are on the CC list for the bug.
RE: Supporting Portrait-First and Landscape-First devices in HTML5 Device Orientation
Sorry for the delay! We've had an opportunity to discuss your suggestions and comments with our internal teams and agree with your approach. The main original concerns we had were: * Creating a dependency between the screen and device orientation specs. Based on your comments this doesn't seem to be a concern. * Breaking existing implementation. Again, based on your comments this doesn't seem to be a concern. The Z axis concerns I stated in my previous message was due to my misunderstanding of how the Z axis is mapped. Tab and Jonas, you are correct, the Z coordinate values are irrespective of how the device is being held (portrait or landscape). We should provide guidance to developers that the X and Y device orientation coordinate axis will be aligned to the current screen orientation. Also, developers should request an orientation lock to avoid the possibility of their device orientation resetting. As a next steps, who is responsible for updating the current device orientation specification? Thanks. Dhruv On Friday, August 16, 2013 10:08 AM, Tab Atkins Jr. [mailto:jackalm...@gmail.com] Because that's nonsensical for landscape devices, or apps who are fine with being rotated to landscape. It's only simpler for spec authors - it requires extra work for web authors. ~TJ
