On Tue, May 24, 2016 at 8:50 PM, Brandon Jones wrote:
>
> but Yaw probably just initializes to whatever position the user started
> with.
>
Applications for these kinds of controllers usually have some "reset
forward" thing. Sometimes the settings of the device do (as is the case
with Oculuses HMD
about the Nintendo Wii controllers!), however. So my
> suggestion to add it to the Gamepad API still stands.
>
> Regards,
> -Sven Neuhaus
>
> Am 23.05.2016 um 15:52 schrieb Florian Bösch:
> > The WebVR API models HMD pose and will model the gesture controllers.
> > https://mo
The WebVR API models HMD pose and will model the gesture controllers.
https://mozvr.com/webvr-spec/
On Tue, May 17, 2016 at 9:41 AM, Sven Neuhaus wrote:
> Hello,
>
> I read the gamepad API description at
> https://developer.mozilla.org/en-US/docs/Web/API/Gamepad
>
> I think the gamepad API shoul
On Mon, Apr 25, 2016 at 4:31 AM, Chris Van Wiemeersch
wrote:
>
> If you take a look at all the content libraries out there for the Gamepad
> API, there's a ridiculous amount of logic and special casing web developers
> are having to do just between the Firefox and Chrome implementations - and
> be
On Tue, Feb 23, 2016 at 7:06 PM, Joshua Bell wrote:
> On Tue, Feb 23, 2016 at 7:12 AM, Florian Bösch wrote:
>
>> On Tue, Feb 23, 2016 at 2:48 AM, Jonas Sicking wrote:
>>
>>> Is the last bullet here really accurate? How can you use existing APIs
>>> to li
On Tue, Feb 23, 2016 at 2:48 AM, Jonas Sicking wrote:
> Is the last bullet here really accurate? How can you use existing APIs to
> listen to file modifications?
>
I have not tested this on all UAs, but in Google Chrome what you can do is
to set an interval to check a files.lastModified date, and
use TCP/IP (which guarantees
ordering)...
On Wed, Dec 2, 2015 at 3:54 PM, Richard Barnes wrote:
>
>
> On Wed, Dec 2, 2015 at 9:36 AM, Florian Bösch wrote:
>
>> 1) Encryption between Alice and Bob by means of an asymmetric
>> public/private key exchange protocol cann
Dec 2, 2015 at 2:05 PM, Aymeric Vitte
wrote:
>
>
> Le 02/12/2015 13:18, Florian Bösch a écrit :
> > On Wed, Dec 2, 2015 at 12:50 PM, Aymeric Vitte > <mailto:vitteayme...@gmail.com>> wrote:
> >
> > Then you should follow your rules and apply this policy to
On Wed, Dec 2, 2015 at 12:50 PM, Aymeric Vitte
wrote:
>
> Then you should follow your rules and apply this policy to WebRTC, ie
> allow WebRTC to work only with http.
>
Just as a sidenote, WebRTC also does UDP and there's no TLS over UDP. Also
WebRTC does P2P, and there's no certificates/authorit
On Mon, Nov 30, 2015 at 10:45 PM, Richard Barnes
wrote:
> 1. Authentication: You know that you're talking to who you think you're
> talking to.
>
And then Dell installs a their own root authority on machines they ship, or
your CA of choice gets pwn'ed or the NSA uses some undisclosed backdoor in
On Sun, Nov 1, 2015 at 9:08 PM, Vincent Scheib wrote:
>
> Thanks for clarifying. Basic usage is demonstrated in the wild but some
> edge cases should have clear demonstration in the test suite. I will
> generate those as other project priorities allow (and would of course
> review any from others)
I think you underestimate the integrative need that web-apps will acquire
and the lengths they will go to faced with a business need to make it work
once "clipboard API" becomes common developer knowledge.
My point is that if you leave no other way out, that is what will happen.
On Thu, Jun 25, 2015 at 7:57 PM, Daniel Cheng wrote:
> That's the case today already, and I haven't seen this happening.
>
> Daniel
>
> On Thu, Jun 25, 2015 at 10:48 AM Florian Bösch wrote:
&
y to support it anytime soon.
>
> Daniel
>
> On Thu, Jun 25, 2015 at 10:38 AM Florian Bösch wrote:
>
>> Yet you restrict mime-types AND you support application/octet-stream?
>>
>> On Thu, Jun 25, 2015 at 7:34 PM, Daniel Cheng wrote:
>>
>>> For reason
to risk their paste turning into thousands of lines of
> gibberish because they tried to stuff binary data in text/plain.
>
> Daniel
>
>
> On Thu, Jun 25, 2015 at 8:23 AM Florian Bösch wrote:
>
>> No, what I'm saying is that if you restrict mime types (or don't
>&
the clipboard in that format (given that platform native clipboards each
> have their own content-type annotations).
>
> So it sounds like you're saying we should also remove
> application/octet-stream as a mandatory format?
>
> On Thu, 25 Jun 2015 at 15:55 Florian Bösch wr
of what it means in this context) by putting the content
> on the clipboard as an un-typed file?
>
> Again, I'm unclear as to what the alternative is that you're proposing?
>
> On Thu, 25 Jun 2015 at 15:27 Florian Bösch wrote:
>
>> Surely you realize that if the spec
give rise to widely confusing and homebrewn workarounds till out of
that broil another mime-type standard emerged that browsers sought to
repress.
On Thu, Jun 25, 2015 at 4:30 PM, Florian Bösch wrote:
> I'm pretty sure it can't be in the interest of this specification to force
>
al system clipboard. The spec doesn't currently mandate OpenEXR be
>> supported, so it's currently up to individual user agents to decide whether
>> they can support that format safely.
>>
>> On Thu, 25 Jun 2015 at 14:16 Florian Bösch wrote:
>>
>>> O
it's currently up to individual user agents to decide whether they can
> support that format safely.
>
> On Thu, 25 Jun 2015 at 14:16 Florian Bösch wrote:
>
>> On Thu, Jun 25, 2015 at 3:13 PM, Wez wrote:
>>
>>> I think there's obvious value in support for arb
On Thu, Jun 25, 2015 at 3:13 PM, Wez wrote:
> I think there's obvious value in support for arbitrary content-specific
> formats, but IMO the spec should at least give guidance on how to present
> the capability in a safe way.
>
Which is exactly the core of my question. If you intend to make it sa
On Thu, Jun 25, 2015 at 2:58 PM, Florian Bösch wrote:
> the magic bytes of an OpenEXR?
>
Which is 0x762f3101 btw.
Or should we just place that into "application/octet-stream" and hope
whoever listens for the clipboard scans the magic bytes of an OpenEXR?
On Thu, Jun 25, 2015 at 2:56 PM, Florian Bösch wrote:
> Well let's say some webapp generates an OpenEXR and wants to put it into
> th
PEG
> or PNG and place it directly on the local system clipboard.
>
> What is it that you're actually proposing?
>
> On Thu, 25 Jun 2015 at 13:31 Florian Bösch wrote:
>
>> No idea. Also doesn't matter jack. There could be some now or in the
>> future. There
No idea. Also doesn't matter jack. There could be some now or in the
future. There's a variety of programs that support HDRi (photoshop,
lightroom, hdri-studio, etc.). It's fairly logical that at some point some
or another variant of HDR format will make its way into clipboards. The
same applies to
t; Events spec, is it..?
>
> On Wed, Jun 24, 2015, 18:49 Florian Bösch wrote:
>
>> And how exactly do you intend to support for instance OpenEXR?
>>
>> On Wed, Jun 24, 2015 at 5:44 PM, Wez wrote:
>>
>>> Hallvord,
>>>
>>> Yes, content would b
And how exactly do you intend to support for instance OpenEXR?
On Wed, Jun 24, 2015 at 5:44 PM, Wez wrote:
> Hallvord,
>
> Yes, content would be limited to providing text, image etc data to the
> user agent to place on the clipboard, and letting the user agent synthesize
> whatever formats (JPEG
On Thu, Jun 11, 2015 at 8:32 PM, Daniel Cheng wrote:
>
> On Thu, Jun 11, 2015 at 11:13 AM Florian Bösch wrote:
>
>> What about JPEG 2000, Exif, TIFF, RIF, BMP, PM, PGM, PBM, PNM, HDR, EXR,
>> BPG, psd, xcf, etc.?
>>
> I'm not sure what you're trying to say
What about JPEG 2000, Exif, TIFF, RIF, BMP, PM, PGM, PBM, PNM, HDR, EXR,
BPG, psd, xcf, etc.?
Besides, if html clipboards will be crippled beyond usability by security
paranoia, you'll just use good'ol flash to copy your random bytes to the
clipboard again.
If you can't put an image/png into a clipboard from JS, you just put it
into an application/octet-stream, which many image editors will load just
happily. If that doesn't work, you just stick your PNG into a plain/text,
which many image editors will still load just fine.
Oh, also while you're on crippling things, please also exclude copying any
text that contains "http://:"; cause that borks skype.
On a further note. If UAs (which are among the more prevalent applications
out there being used) intentionally disable declaring mime-types for some
classes of content, so that it can't be pasted into applications that might
not be equipped to handle those mimetypes, application programmers (such a
Wait, why are you talking about removing an ostensibly useful feature
(declaring a mimetype in a paste for certain mime types) because the end
result could land up in the users paste, where it could be pasted into
applications that're not equipped to handle random assemblages of bytes,
even though
ly it to axes given that there are effectively two
> inputs working simultaneously.
>
> Ashley
>
>
> On 9 April 2015 at 22:29, Florian Bösch wrote:
>
>> The polling model for axes has a significant advantage as I'll illustrate.
>>
>> Suppose you're ste
The polling model for axes has a significant advantage as I'll illustrate.
Suppose you're steering a cursor of some kind in 2 dimensions. That cursor
would also draw a trail/line whatever. Here's what happens if you apply
this logic on events per axis: You get a staircase. Why? Because the X-axis
If my reading is correct, there is no provision to escape a mapping that
the UA would apply? I've observed in the past that the mappings can go
quite awry. Would it be possible to offer a way toggle off mapping on a
gamepad?
On Thu, Apr 9, 2015 at 1:52 PM, Arthur Barstow
wrote:
> Hi All,
>
> A n
On Thu, Apr 2, 2015 at 2:40 PM, Anders Rundgren <
anders.rundgren@gmail.com> wrote:
>
> Obviously we need a model where the code is "vetted" for
> DoingTheRightThing(tm).
>
This is essentially about two things: trust and the capability to "vet".
Both of these things cannot be solved conclusive
On Wed, Apr 1, 2015 at 9:00 PM, Anders Rundgren <
anders.rundgren@gmail.com> wrote:
>
> Who would like to get something like that in their face when buying stuff
> on the web?
14% of users recognize changes in content of a security prompt. An MRI scan
shows that at the second security prompt
sly...
On Wed, Apr 1, 2015 at 6:44 PM, Jonas Sicking wrote:
> On Wed, Apr 1, 2015 at 6:37 PM, Florian Bösch wrote:
> > On Wed, Apr 1, 2015 at 6:02 PM, Jonas Sicking wrote:
> >>
> >> Not saying that we can use CORS to solve this, or that we should
> >> extend C
On Wed, Apr 1, 2015 at 6:02 PM, Jonas Sicking wrote:
> Not saying that we can use CORS to solve this, or that we should
> extend CORS to solve this. My point is that CORS works because it was
> specified and implemented across browsers. If we'd do something like
> what Domenic proposes, I think t
On Wed, Apr 1, 2015 at 11:22 AM, Nilsson, Claes1 <
claes1.nils...@sonymobile.com> wrote:
> Hi all,
>
>
>
> Related to the recent mail thread about the SysApps WG and its
> deliverables I would like to make a report of the status of the TCP and UDP
> Socket API, http://www.w3.org/2012/sysapps/tcp-u
On Wed, Apr 1, 2015 at 1:49 AM, Vincent Scheib wrote:
>
> You raised this point in 2011, resulting in my adding this spec section
> you reference. The relevant bit being:
> """
> ... a concern of specifying what units mouse movement data are provided
> in. This specification defines .movementX/Y p
On Sun, Mar 29, 2015 at 2:38 PM, Jonas Sicking wrote:
> On Sun, Mar 29, 2015 at 1:25 PM, Florian Bösch wrote:
> > It's been over 2 years since I raised this issue the first time. The
> > specification has not been http://www.w3.org/TR/file-writer-api/
> updated in
> &
It's been over 2 years since I raised this issue the first time. The
specification has not been http://www.w3.org/TR/file-writer-api/ updated in
a year and it states that:
Work on this document has been discontinued and it should not be referenced
> or used as a basis for implementation.
The pro
On Sat, Mar 21, 2015 at 10:47 PM, Florian Bösch wrote:
> 2) MRI scans show that user attention dramatically drops when presented
> with a security prompt:
> http://arstechnica.com/security/2015/03/mris-show-our-brains-shutting-down-when-we-see-security-prompts/
>
It's also lik
Time to revise this topic. Two data points:
1) Particularly with pointerlock (but also with other permission prompts
that sneak up on the user) I often get the complaint from users along the
lines of "I tried your stuff, but it didn't work." or "I tried your stuff,
but it asked me to do X, I don't
I'd like to comment on the pointer lock functionality some.
12.4 notes that capturing a (a native) pointer inside of a rectangle is
difficult. I've done some research into this topic and I can attest that
it's not straightforward. Some platforms have support for this semantics,
others (I think it
On Mon, Feb 16, 2015 at 9:08 AM, Jeffrey Walton wrote:
> I'd hardly consider an account holder's data as high value. Medium at
> best and likely low value. But that's just me.
>
Of course if the data is compromised it means that an attacker can also
remote-control your e-banking interface, and is
On Mon, Feb 16, 2015 at 8:09 AM, Anders Rundgren <
anders.rundgren@gmail.com> wrote:
> Unfortunately this is wrong and is why I started this thread. Mobile
> banking applications in Europe are usually featured as "Apps".
> This has multiple reasons; one is that there's no way to deal with
> cl
On Sun, Feb 15, 2015 at 10:59 PM, Jeffrey Walton wrote:
> For the second point, and as a security architect, I regularly reject
> browser-based apps that operate on medium and high value data because
> we can't place the security controls needed to handle the data. The
> browser based apps are fi
On Tue, Feb 10, 2015 at 4:24 PM, Glenn Adams wrote:
> Morality should not be legislated!
>
Browser vendors can (and do) do whatever they please. You're free to start
your own browser and try getting it among the people. Legislation doesn't
enter the picture, you have free choice in every respect
On Fri, Feb 6, 2015 at 7:38 PM, Michaela Merz
wrote:
> it would be the job of the browser development community to find a way
> to make such calls less harmful.
>
If there was a way to make synchronous calls less harmful, it'd have been
implemented a long time ago. There isn't.
You could servic
>
> I had an Android device, but now I have an iPhone. In addition to the
> popup problem, and the fake "X" on ads, the iPhone browsers (Safari,
> Chrome, Opera) will start to show a site, then they will lock up for 10-30
> seconds before finally becoming responsive.
Via. Ask Slashdot:
http://ask
On Thu, Feb 5, 2015 at 2:44 PM, Takeshi Yoshino wrote:
> IIUC, CORS prevents clients from issuing non-simple cross-origin request
> (even idempotent methods) without verifying that the server understands
> CORS. That's realized by preflight.
>
Incorrect, the browser will perform idempotent reque
.
On Thu, Feb 5, 2015 at 2:41 PM, Anne van Kesteren wrote:
> On Thu, Feb 5, 2015 at 2:39 PM, Florian Bösch wrote:
> > On Thu, Feb 5, 2015 at 2:35 PM, Anne van Kesteren
> wrote:
> >> Wouldn't that require the endpoint to support two protocols? That
> >> sounds subo
On Thu, Feb 5, 2015 at 2:39 PM, Takeshi Yoshino wrote:
> To prevent WebSocket from being abused to attack existing HTTP servers
> from malicious non-simple cross-origin requests, we need to have WebSocket
> clients to do some preflight to verify that the server is not an HTTP
> server that don't
On Thu, Feb 5, 2015 at 2:35 PM, Anne van Kesteren wrote:
> Wouldn't that require the endpoint to support two protocols? That
> sounds suboptimal.
>
CORS and Websockets are two separate protocols which each work off and by
themselves, there is no change required to either to make one work with th
On Thu, Feb 5, 2015 at 2:29 PM, Bjoern Hoehrmann wrote:
> It seems to me that "pre-flight" requests would happen prior to opening
>
Pre-flight request will not be made for GET, HEAD and OPTIONS as is
customary for idempotent requests and as is specified by CORS.
will break existing deployments.
Either way, this will result in no change made, so you can burry it right
here.
On Thu, Feb 5, 2015 at 2:12 PM, Anne van Kesteren wrote:
> On Thu, Feb 5, 2015 at 1:27 PM, Florian Bösch wrote:
> > CORS is an adequate protocol to allow for additi
On Thu, Feb 5, 2015 at 1:22 PM, Anne van Kesteren wrote:
>
> I'm not sure how this is relevant. We are discussing adding the
> ability to the WebSocket API to set custom headers and whether the
> current protocol is adequate for that.
>
CORS is an adequate protocol to allow for additional headers
On Thu, Feb 5, 2015 at 12:59 PM, Anne van Kesteren wrote:
> That is not sufficient to allow custom headers. Cross-origin (and
> WebSocket is nearly always cross-origin I think) custom headers
> require a preflight and opt-in on a per-header basis.
>
Access-Control-Allow-Headers is not a preflight
+1 https://www.w3.org/Bugs/Public/show_bug.cgi?id=27444
On the polling vs. live object.
- I'd be nice if there was a way to poll but not allocate a new object
everytime. This has been relegated to "oh we'll get better GCs in JS
eventually, let's not structure our API around not having a
It gives you at least a sandboxed file system, which is about all you can
offer without a central authority to make infallible decisions, decisions
you'd pay for to get.
On Wed, Nov 19, 2014 at 8:35 AM, Jonas Sicking wrote:
> On Tue, Nov 18, 2014 at 9:38 PM, Florian Bösch wrote:
> &
On Wed, Nov 19, 2014 at 7:54 AM, Marc Fawzi wrote:
>
> So there is no way for an unsigned script to exploit security holes in a
> signed script?
>
Of course there's a way. But by the same token, there's a way a signed
script can exploit security holes in another signed script. Signing itself
doesn
There are some models that are a bit better than trust by royalty
(app-stores) and trust by hirarchy (TLS). One of them is trust flowing
along flow limited edges in a graph (as in Advogato). This model however
isn't free from fault, as when a highly trusted entity gets compromised,
there's no quick
On Wed, Nov 19, 2014 at 6:35 AM, Michaela Merz
wrote:
> Well .. it would be a "all scripts signed" or "no script signed" kind of
> a deal. You can download malicious code everywhere - not only as scripts.
> Signed code doesn't protect against malicious or bad code. It only
> guarantees that the
On Wed, Nov 19, 2014 at 5:00 AM, Michaela Merz
wrote:
>
> If signed code would allow
> special features - like true fullscreen
https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Using_full_screen_mode
> or direct file access
http://www.html5rocks.com/en/tutorials/file/filesystem/
On Wed, Nov 19, 2014 at 4:26 AM, Michaela Merz
wrote:
> First: We need signed script code. We are doing a lot of stuff with
> script - we could safely do even more, if we would be able to safely
> deliver script that has some kind of a trust model.
TLS exists.
> I am thinking about
> signed JA
I've been looking into mapping input devices for a fair while, and I think
it's not a straighforward problem to solve for a UA (or even a OS).
Difficulties include, but are not limited to:
- Buttons reported by the driver as axes
- Axes reported by the driver as buttons
- Buttons which a
Note that events for axis input can (when wrongly handled) lead to
undesirable behavior. For instance, suppose you have a 2-axis input you use
to plot a line on screen. If you poll the positions and then draw a line
from the last position to the current position, you will get a smooth line.
However
On Fri, Sep 5, 2014 at 11:14 AM, Mounir Lamouri wrote:
> Note that the Permissions API model isn't requiring all APIs to abide by
> its model. Having no permissions at all for an API is a decent model if
> possible. For example, having a permission concept for type='file'> doesn't make much sens
On Thu, Sep 4, 2014 at 10:36 PM, Jeffrey Walton wrote:
> A site that continually prompts the user could negatively affect the
> user experience. If the designers of the site appreciate the fact,
> then they might ask for fewer permissions. They might even segregate
> functionality into different
On Thu, Sep 4, 2014 at 10:18 PM, Marcos Caceres wrote:
> This sets up an unrealistic straw-man. Are there any real sites that would
> need to show all of the above all at the same time?
Let's say you're writing a video editor, you'd like:
- To get access to the locations API so that you can
This is an issue to use, for a user.
- http://codeflow.org/issues/permissions.html
- http://codeflow.org/issues/permissions.jpg
- In firefox it's a succession of popup
It's also an issue to use for a developer, because the semantics and
methods for requesting, getting, being denied and m
I welcome this proposal because the permission dialog creep is certainly
worrying.
Opponents of some kind of permission management have pointed out that
collated dialogs tend to just get ignored by users and blindly approved (as
an example they list Android permission handling).
While that may be
There's two aspects that should not be overlooked.
1. Some events only make sense in unison. For instance the input of a
2-axis knob. On many OS implementations, change events for each axis arrive
separately in short succession. However to an application programmer,
getting first the X
I think both semantics are workable. I'd likely prefer the gamepad state to
be immutable from JS, because assigning state there is smelly. I'd also
prefer the option that incurs less GC overhead if possible. Beyond that, I
just think the implementations should be semantically and symbolically
ident
(note that when I list an inconceivable amount of ridiculous device APIs to
add, it's meant as satire of the idea that you should make a specialized
API for every assemblage of sensors, motors and displays)
On Fri, Apr 4, 2014 at 4:45 PM, Florian Bösch wrote:
> On Fri, Apr 4, 2014 at
On Fri, Apr 4, 2014 at 4:35 PM, Kostiainen, Anssi <
anssi.kostiai...@intel.com> wrote:
> One way to spec that would be to make Vibration its own interface, and say
> GamePad implements Vibration. For more advanced use cases (borrowing one
> from your list):
>
> interface SteeringWheel {
> readon
On Fri, Apr 4, 2014 at 4:15 PM, Ted Mielczarek wrote:
> Gamepad.vibrate method that works like navigator.vibrate. I don't know
> if this is what we want to do, but it's worth investigating so we don't
> reinvent the wheel if we don't have to.
>
How do you know which of the two (or more?) motors
On Fri, Apr 4, 2014 at 3:45 PM, Kostiainen, Anssi <
anssi.kostiai...@intel.com> wrote:
> In the initial versions of the spec we indeed considered such reuse.
> Here's my recent summary:
>
> http://lists.w3.org/Archives/Public/public-device-apis/2014Apr/0002.html
If you have a navigator.gamepa
On Thu, Apr 3, 2014 at 8:07 PM, Ted Mielczarek wrote:
> Note: DirectInput has been deprecated in favor of XInput, a much simpler
> API that maps directly to the Xbox 360 controller:
>
> http://msdn.microsoft.com/en-us/library/windows/desktop/ee417001%28v=vs.85%29.aspx
>
XInput is kinda useless
specific usecases is what is a monolythic monster API that
tries to be everything and the kitchensink in the end.
On Thu, Apr 3, 2014 at 5:55 PM, Patrick H. Lauke wrote:
> On 03/04/2014 16:43, Florian Bösch wrote:
>
>> But even so, what do you want to end up with?
>>
>
> Wh
On Thu, Apr 3, 2014 at 5:19 PM, Ted Mielczarek wrote:
>
> Spec'ing standard rumble motors that are found on all modern controllers
> seems sensible. Spec'ing a way to access a microphone/speaker that's
> present on a controller seems sensible. I think anything more complicated
> than that is likel
Replied to Brandon Jones but not public, reposted below.
On Wed, Mar 26, 2014 at 7:18 PM, Brandon Jones wrote:
>
> As for things like eye position and such, you'd want to query that
> separately (no sense in sending it with every device), along with other
> information about the device capabiliti
On Mon, Feb 24, 2014 at 8:21 PM, Glenn Maynard wrote:
>
> I think that going fullscreen is the right approach, since locking the
> mouse into the window while not fullscreen is really weird and rare, at
> least in Windows.
>
It's quite common for games to have a cursor, grab the pointer and not be
't
be perceptively different from an OS cursor.
On Mon, Feb 24, 2014 at 7:41 PM, Vincent Scheib wrote:
>
>
>
> On Mon, Feb 24, 2014 at 10:37 AM, Florian Bösch wrote:
>
>> On Mon, Feb 24, 2014 at 7:07 PM, Vincent Scheib wrote:
>>
>>> Windows has ClipCurso
On Mon, Feb 24, 2014 at 7:07 PM, Vincent Scheib wrote:
> Windows has ClipCursor() and Linux has XGrabPointer(). Once we know we can
> implement the functionality, we can discuss how to express this in an API.
>
Would using Quarz CGWarpMouseCursorPosition work where you'd clamp the
passed positio
On Mon, Feb 24, 2014 at 6:47 PM, Brendan Eich wrote:
> Glenn Maynard wrote:
>
>> It's not the application's job to keep the mouse cursor responsive, it's
>> the system's. Hiding the system mouse cursor and drawing one manually is
>> always a bad idea.
>>
>
> Agreed!
>
Like I say, some usecases a
On Mon, Feb 24, 2014 at 5:40 PM, Glenn Maynard wrote:
> (More reasons: it's very likely that you'll end up implementing a cursor
> with different motion and acceleration, a different "feel", than the real
> mouse cursor. It also breaks accessibility features, like mouse trails.)
>
Oh I agree, if
On Mon, Feb 24, 2014 at 5:18 PM, Glenn Maynard wrote:
>
> It's not the application's job to keep the mouse cursor responsive, it's
> the system's. Hiding the system mouse cursor and drawing one manually is
> always a bad idea.
>
That's a wonderful argument. And now we look at an FPS game, or an
On Mon, Feb 24, 2014 at 1:16 AM, Thibaut Despoulain
wrote:
> I've written a test for this here:
>> http://codeflow.org/issues/software-cursor.html
>>
>> My observation from testing on linux is that I can't distinguish latency
>> for the software cursor from the OS cursor (or not by much anyway) in
On Sun, Feb 23, 2014 at 4:18 PM, Brandon Jones wrote:
> - it's possible to theme the OS cursor using custom images with CSS.
> https://developer.mozilla.org/en-US/docs/Web/CSS/cursor/url
>
Although that doesn't absolve vendors from fixing the latency issue even if
native pointers where to be made
On Sun, Feb 23, 2014 at 9:55 AM, Florian Bösch wrote:
>
>>- Inability to use DOM elements with mouse events for a game
>>overlay/HUD.
>>
>> The test I've written here
> http://codeflow.org/issues/software-cursor.html also tests mouse event
> synthe
On Sun, Feb 23, 2014 at 1:57 AM, Thibaut Despoulain
wrote:
> The issue with pointerlock is that it requires the app to draw its own
> cursor instead of the OS cursor
>
I fully agree with motivation, it is usually preferrable to give the user
an OS-themed cursor (not always, but often).
>
>-
Pointerlock should solve these problems in the following fashion:
- When the user clicks into the app, request pointerlock
- Use it to give him a cursor drawn by you
- That way you can keep the interaction inside your game and accurately
detect borders etc.
I run http://webglstats.com
On Sat, Feb 22, 2014 at 11:22 PM, Florian Bösch wrote:
> Caveat, I think Firefoxes implementaiton of the Pointerlock API might not
> follow the specification yet to make it possible to have pointerlock
> without fullscreen.
>
Just checked this against a test I wrote a wh
I think the user unfriendlyness derives from that you can't open that page
which you've played before and have it just work. Maybe the UA could
remember the devices you enabled?
On Tue, May 7, 2013 at 8:09 AM, Jonas Sicking wrote:
> > You're arguing for allowing accessing files inside ZIPs by URL, which
> means
> > you're going to have to do the work anyway, since you'd be able to
> create a
> > blob URL, reference a file inside it using XHR, and get a Blob as a
> result
1 - 100 of 226 matches
Mail list logo
