[no subject]
Hi,I think that there's a problem with the current spec of CORS.When attempting to perform a preflight with a non-anonymous website, the preflight is bound to fail because no Authorization header is being sent.This poses a problem at least for IIS users who are using a Classic Application Pool, and apparently cannot interfere with the Return Code (which is 401).Please review discussion here:https://bugzilla.mozilla.org/show_bug.cgi?id=778548Thanks.
[no subject]
Hi,I think that there's a problem with the current spec of CORS.When attempting to perform a preflight with a non-anonymous website, the preflight is bound to fail because no Authorization header is being sent.This poses a problem at least for IIS users who are using a Classic Application Pool, and apparently cannot interfere with the Return Code (which is 401).Please review discussion here:https://bugzilla.mozilla.org/show_bug.cgi?id=778548Thanks.
Re: CORS spec error (?)
On Mon, Jul 30, 2012 at 1:49 PM, ewolf...@yahoo.com wrote: I think that there's a problem with the current spec of CORS. When attempting to perform a preflight with a non-anonymous website, the preflight is bound to fail because no Authorization header is being sent. This poses a problem at least for IIS users who are using a Classic Application Pool, and apparently cannot interfere with the Return Code (which is 401). Please review discussion here: https://bugzilla.mozilla.org/show_bug.cgi?id=778548 I don't really see any other way than waiting for those servers to be obsoleted. -- http://annevankesteren.nl/
F2F meeting Oct 29-30 in Lyon France; registration deadline Oct 16
Hi All, As announced earlier, WebApps will have a f2f meeting October 29-30 as part of the W3C's annual Technical Plenary Week http://www.w3.org/2012/10/TPAC/ in Lyon France. WebApps' meeting page is http://www.w3.org/wiki/Webapps/TPAC2012Meeting. We will again preallocate some time slots for specific agenda topics and use an unconference style meeting to determine the remainder of agenda topics. Proposed agenda topics are welcome at any time, via e-mail or updating the meeting page. Registration for the meeting is required and there is a €45 per day fee http://www.w3.org/2012/10/TPAC/#Registration that increases to €135 per day on October 17. The Technical Plenary meeting is all day Wednesday October 31. This meeting (now mostly an unconference style) is often a good way to learn about and discuss more general topics. See the 2011 TPAC agenda for more info http://www.w3.org/wiki/TPAC2011#Session_Grid. NOTE: the TPAC meeting page includes the following warning *It is strongly recommended to make hotel reservations as soon as possible as there will be other meetings at the conference center.* -Thanks, AB
Re: [gamepad] Polling access point
On Thu, Jul 26, 2012 at 9:20 PM, Scott Graham scot...@chromium.org wrote: There's no particular indication at the spec level to indicate stopping the gamepad polling, based on the assumption that it's an implementation detail. Maybe there should be some way for content to hint that though? I guess an implementation could timeout and shutdown background resources if the content does not request data for some amount of time too. I was thinking that this isn't much different than the use case in the geolocation API spec[1]. Perusing that spec shows that it has watchPosition / clearWatch APIs for explicitly registering/unregistering for location updates. I don't know if I particularly want to add an API like that, but conceptually we might want something like that. In my current implementation in Firefox, the background polling is triggered by the page adding event listeners for one of the DOM events. I don't recall offhand if unregistering for the events stops the polling, or if it takes having the document unloaded. -Ted 1. http://www.w3.org/TR/geolocation-API/
Re: [selectors-api] RfC: LCWD of Selectors API Level 1; deadline July 19
On 7/19/12 11:15 PM, ext Kang-Hao (Kenny) Lu wrote: Sorry for my late comment. While I think it's fine to publish LCWD Selectors API as it is, it would be nice if it can address my comment in [1]. By address, I mean either define the desired behavior or explicitly mark it as undefined (which I think is better than not saying anything because an explicit undefined tells a spec reader that relevant discussions can be found in the list). [1] http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/thread#msg518 Lachlan, Kenny - what is the status of this comment (f.ex. does the spec need to be changed)? -Thanks, Art
allowfullscreen vs sandbox=allow-fullscreen, and mimicking for pointer lock
I'm currently implementing Pointer Lock [1] in WebKit, which was adjusted recently to mimic Fullscreen [2]. Why does the Fullscreen specification use an iframe attribute allowfullscreen to permit/restrict iframe capabilities instead of using iframe sandbox=allow-fullscreen? [1] http://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html [2] http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html
Re: allowfullscreen vs sandbox=allow-fullscreen, and mimicking for pointer lock
[correcting Anne van Kesteren's email] On Tue, Jul 31, 2012 at 3:03 PM, Vincent Scheib sch...@google.com wrote: I'm currently implementing Pointer Lock [1] in WebKit, which was adjusted recently to mimic Fullscreen [2]. Why does the Fullscreen specification use an iframe attribute allowfullscreen to permit/restrict iframe capabilities instead of using iframe sandbox=allow-fullscreen? [1] http://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html [2] http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html
Re: [whatwg] allowfullscreen vs sandbox=allow-fullscreen, and mimicking for pointer lock
It looks like the ability to go full screen is off-by-default and then enabled via the attribute. If we used iframe@sandbox, the ability would be on-by-default for non-sandboxed iframes. Adam On Tue, Jul 31, 2012 at 3:11 PM, Vincent Scheib sch...@google.com wrote: [correcting Anne van Kesteren's email] On Tue, Jul 31, 2012 at 3:03 PM, Vincent Scheib sch...@google.com wrote: I'm currently implementing Pointer Lock [1] in WebKit, which was adjusted recently to mimic Fullscreen [2]. Why does the Fullscreen specification use an iframe attribute allowfullscreen to permit/restrict iframe capabilities instead of using iframe sandbox=allow-fullscreen? [1] http://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html [2] http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html
Re: [whatwg] allowfullscreen vs sandbox=allow-fullscreen, and mimicking for pointer lock
It's not clear to me from the spec how the allowfullscreen attribute works. It appears to be mentioned only in the security and privacy considerations section. For example, suppose I have three frames: Main frame: a.html - iframe src=b.html - iframe src=c.html allowfullscreen Can c.html go full screen? Where is that specified? Adam On Tue, Jul 31, 2012 at 3:26 PM, Adam Barth w...@adambarth.com wrote: It looks like the ability to go full screen is off-by-default and then enabled via the attribute. If we used iframe@sandbox, the ability would be on-by-default for non-sandboxed iframes. Adam On Tue, Jul 31, 2012 at 3:11 PM, Vincent Scheib sch...@google.com wrote: [correcting Anne van Kesteren's email] On Tue, Jul 31, 2012 at 3:03 PM, Vincent Scheib sch...@google.com wrote: I'm currently implementing Pointer Lock [1] in WebKit, which was adjusted recently to mimic Fullscreen [2]. Why does the Fullscreen specification use an iframe attribute allowfullscreen to permit/restrict iframe capabilities instead of using iframe sandbox=allow-fullscreen? [1] http://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html [2] http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html
Re: [whatwg] allowfullscreen vs sandbox=allow-fullscreen, and mimicking for pointer lock
On Wed, Aug 1, 2012 at 10:33 AM, Adam Barth w...@adambarth.com wrote: It's not clear to me from the spec how the allowfullscreen attribute works. It appears to be mentioned only in the security and privacy considerations section. For example, suppose I have three frames: Main frame: a.html - iframe src=b.html - iframe src=c.html allowfullscreen Can c.html go full screen? Where is that specified? The intent is that no, it can't. You're right that this is currently unspecified. Rob -- “You have heard that it was said, ‘Love your neighbor and hate your enemy.’ But I tell you, love your enemies and pray for those who persecute you, that you may be children of your Father in heaven. ... If you love those who love you, what reward will you get? Are not even the tax collectors doing that? And if you greet only your own people, what are you doing more than others? [Matthew 5:43-47]