Re: [whatwg] allowfullscreen vs sandbox="allow-fullscreen", and mimicking for pointer lock

2012-07-31 Thread Adam Barth 
On Tue, Jul 31, 2012 at 10:24 PM, Robert O'Callahan
 wrote:
> On Wed, Aug 1, 2012 at 10:33 AM, Adam Barth  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
>>   -> 
>> -> 
>>
>> 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.

Even if we don't use the iframe@sandbox syntax, it might be worth
re-using the spec machinery because it's good at solving problems like
the above.

Adam

Re: [whatwg] allowfullscreen vs sandbox="allow-fullscreen", and mimicking for pointer lock

2012-07-31 Thread Robert O'Callahan 
On Wed, Aug 1, 2012 at 10:33 AM, Adam Barth  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
>   -> 
> -> 
>
> 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]

Re: [whatwg] allowfullscreen vs sandbox="allow-fullscreen", and mimicking for pointer lock

2012-07-31 Thread Adam Barth 
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
  -> 
-> 

Can c.html go full screen?  Where is that specified?

Adam


On Tue, Jul 31, 2012 at 3:26 PM, Adam Barth  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  wrote:
>> [correcting Anne van Kesteren's email]
>>
>>
>> On Tue, Jul 31, 2012 at 3:03 PM, Vincent Scheib  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

2012-07-31 Thread Adam Barth 
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  wrote:
> [correcting Anne van Kesteren's email]
>
>
> On Tue, Jul 31, 2012 at 3:03 PM, Vincent Scheib  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: allowfullscreen vs sandbox="allow-fullscreen", and mimicking for pointer lock

2012-07-31 Thread Vincent Scheib 
[correcting Anne van Kesteren's email]


On Tue, Jul 31, 2012 at 3:03 PM, Vincent Scheib  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
>
>

allowfullscreen vs sandbox="allow-fullscreen", and mimicking for pointer lock

2012-07-31 Thread Vincent Scheib 
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: [selectors-api] RfC: LCWD of Selectors API Level 1; deadline July 19

2012-07-31 Thread Arthur Barstow 

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

Re: [gamepad] Polling access point

2012-07-31 Thread Ted Mielczarek 
On Thu, Jul 26, 2012 at 9:20 PM, Scott Graham  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/

F2F meeting Oct 29-30 in Lyon France; registration deadline Oct 16

2012-07-31 Thread Arthur Barstow 

Hi All,

As announced earlier, WebApps will have a f2f meeting October 29-30 as 
part of the W3C's annual Technical Plenary Week 
 in Lyon France.


WebApps' meeting page is 
. 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 
 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 .


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: CORS spec error (?)

2012-07-31 Thread Anne van Kesteren 
On Mon, Jul 30, 2012 at 1:49 PM,   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/

[no subject]

2012-07-31 Thread ewolfman 
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]

2012-07-31 Thread ewolfman 
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.