For those with threaded email clients, at Arthur's suggestion I've filed an
issue to track this topic.
http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0040.html.
On Tue, Oct 2, 2012 at 4:50 PM, Rick Waldron wrote:
>
> On Tuesday, October 2, 2012 at 6:14 PM, Florian Bösch wrote:
>
On Tuesday, October 2, 2012 at 6:14 PM, Florian Bösch wrote:
> Speaking from the point of view of a web developer having to use this
> feature. It is quite painful having to perform an end-run about failure modes
> that are unspecified, undocumented and a moving target. In my understanding,
>
Speaking from the point of view of a web developer having to use this
feature. It is quite painful having to perform an end-run about failure
modes that are unspecified, undocumented and a moving target. In my
understanding, this is precisely the intent of a specification, to avoid
such incompatibi
On 10/03/2012 12:59 AM, Florian Bösch wrote:
On Tue, Oct 2, 2012 at 11:52 PM, Olli Pettay mailto:olli.pet...@helsinki.fi>> wrote:
On 10/02/2012 11:55 PM, Florian Bösch wrote:
I'd like to point out that vendors are using additional failure
criteria to determine if pointerlock succee
I agree that pointer lock is quite useful outside of fullscreen, but
before attempting to codify that in the specification I would want buy
in from other browser vendors. I can appreciate an argument to remain
restricted to fullscreen.
Application developers can automatically escalate to requestin
On Tue, Oct 2, 2012 at 11:52 PM, Olli Pettay wrote:
> On 10/02/2012 11:55 PM, Florian Bösch wrote:
>
>> I'd like to point out that vendors are using additional failure criteria
>> to determine if pointerlock succeeds that are not outlined in the
>> specification. Firefox uses the fullscreen change
On 10/02/2012 11:55 PM, Florian Bösch wrote:
I'd like to point out that vendors are using additional failure criteria to
determine if pointerlock succeeds that are not outlined in the
specification. Firefox uses the fullscreen change event to determine failure
and chrome requires the pointer lo
I'd like to point out that vendors are using additional failure criteria to
determine if pointerlock succeeds that are not outlined in the
specification. Firefox uses the fullscreen change event to determine
failure and chrome requires the pointer lock request to fail if not
resulting from a user i
On 27/09/12 08:37, Vincent Scheib wrote:
On Wed, Sep 26, 2012 at 9:17 AM, Arthur Barstow wrote:
On 9/26/12 11:46 AM, ext Vincent Scheib wrote:
On Wed, Sep 26, 2012 at 7:27 AM, Arthur Barstow
wrote:
* Pointer Lock - Vincent - what's the status of the spec and its
implementation?
Firefox 14 a
On Wed, Sep 26, 2012 at 9:17 AM, Arthur Barstow wrote:
> On 9/26/12 11:46 AM, ext Vincent Scheib wrote:
>>
>> On Wed, Sep 26, 2012 at 7:27 AM, Arthur Barstow
>> wrote:
>>>
>>> * Pointer Lock - Vincent - what's the status of the spec and its
>>> implementation?
>>
>> Firefox 14 and Chrome 22 shipp
On 9/26/12 11:46 AM, ext Vincent Scheib wrote:
On Wed, Sep 26, 2012 at 7:27 AM, Arthur Barstow wrote:
* Pointer Lock - Vincent - what's the status of the spec and its implementation?
Firefox 14 and Chrome 22 shipped Pointer Lock implementations to
stable channel users recently. (Check out this
11 matches
Mail list logo