Re: Lazy Blob

On Wed, Aug 1, 2012 at 9:50 PM, Glenn Adams wrote: > Further, a default behavior in the absence of such an injection might be > defined simply to read data from the WS and stuff into the blob. > Which kind of defeats the purpose because you wanted to read ranges, so not a whole resource has to be

Re: Lazy Blob

On Wed, Aug 1, 2012 at 6:51 PM, Glenn Adams wrote: > I'm questioning defining a "LazyBlob" that is solely usable with XHR. It > would be better to have a more generic version IMO. > Websockets have no content semantics, therefore any lazy content negotiating reader cannot deal with websockets unl

Re: Lazy Blob

On Wed, Aug 1, 2012 at 6:40 PM, Glenn Adams wrote: > Why restrict to XHR? How about WebSocket as data source? > Websockets support array buffers and therefore by extension any blob/file object. However as a stream oriented API websockets have no content aquisition, negotation, range and transfer

Re: Lazy Blob

On Thu, Aug 2, 2012 at 5:45 PM, Glenn Adams wrote: > No it hasn't. If you want a real world use case it is this: my > architectural constraints as an author for some particular usage requires > that I use WS rather than XHR. I wish to have support for the construct > being discussed with WS. How

Re: Lazy Blob

On Thu, Aug 2, 2012 at 6:37 PM, Glenn Adams wrote: > I am not proposing a "particular browser supported semantic" for a > "specific implementation on the server". I have suggested, by way of > example, two particular patterns be supported independently of any such > implementation. I did not rest

Drawing Tablets

I'm interested in drawing tablets and I wonder how that might appear in browsers. Typically drawing tablets have these properties: - PenID: The current pen ID being used - Tool type: the classification of the pen - Proximity: in range of the magnet-resonance sensors - Distance: distance over the

Re: Lazy Blob

On Wed, Aug 1, 2012 at 9:26 PM, Glenn Adams wrote: > So? Why should lazy blob be specific to HTTP specific semantics when an > arbitrary URL is not specific to HTTP? > Reading a resource at arbitrary locations requires two things: 1) That a resource is understood as a container of bytes having

Re: Lazy Blob

On Thu, Aug 2, 2012 at 5:58 PM, Glenn Adams wrote: > All WS usage requires a particular (application specific) implementation > on the server, does it not? Notwithstanding that fact, such usage will fall > into certain messaging patterns. I happened to give an example of two > possible message pa

Re: Lazy Blob

On Wed, Aug 1, 2012 at 10:13 PM, Glenn Adams wrote: > The subject line says Lazy Blob, not Lazy Blob and XHR. For the record, I > will object to a LazyBlob solution that is tied solely to XHR, so deal with > it now rather than later. > Then you better get onto specifying a resource/range transfe

Re: Lazy Blob

On Wed, Aug 1, 2012 at 7:57 PM, Glenn Adams wrote: > blob = > bb.getBlobFromURL("ws://specifiction.com/image/kitten.png > ") > There is no application layer transfer protocol inherent in websockets. Requesting a resource does not have any inherent meaning oth

Drawing Tablets

I'm interested in drawing tablets and I wonder how that might appear in browsers. Typically drawing tablets have these properties: - PenID: The current pen ID being used - Tool type: the classification of the pen - Proximity: in range of the magnet-resonance sensors - Distance: distance over the

Re: Drawing Tablets

On Fri, Aug 3, 2012 at 8:09 AM, Charles Pritchard wrote: > Touch events v2 has some properties, such as pressure Although lacking most other properties (Z, tilt, rotation etc.) > InkML covers the full serialization of captured data. > It looked fairly complete, though I was missing the pen typ

Re: Drawing Tablets

On Fri, Aug 3, 2012 at 6:12 PM, Charles Pritchard wrote: > WebGL vectors map well to brush traces. > One would process a trace group into an int or float array then upload > that to webgl for rendering. > Or, one might use that array to render via Canvas 2d. > It's a little more complex than tha

Re: Drawing Tablets

On Fri, Aug 3, 2012 at 6:54 PM, Charles Pritchard wrote: > As I understand it, the browsers have mature event queues; and > everything comes with a timestamp. > We've got requestAnimationFrame as our primary loop for processing the > queue. > > To clear a queue (so to speak), I believe one simpl

Re: Drawing Tablets

On Fri, Aug 3, 2012 at 7:21 PM, Charles Pritchard wrote: > What kind of correlated events are you thinking of? > For instance most tablet drivers deliver X/Y events separately. If you processed those individually, fast brushstrokes would become staircases. To avoid that, developers filter the qu

Re: GamepadObserver (ie. MutationObserver + Gamepad)

On Sat, Aug 4, 2012 at 12:52 AM, Glenn Maynard wrote: > On Mon, May 7, 2012 at 2:33 PM, Scott Graham wrote: > >> - As you point out, the 360 controller is by far the most common PC >> gamepad, and on its native platforms its standard API XInput is >> exclusively polling based [4]. That doesn't m

Re: GamepadObserver (ie. MutationObserver + Gamepad)

On Sat, Aug 4, 2012 at 3:11 AM, Glenn Maynard wrote: > On a quick test, Firefox is firing mousemove events at 120Hz; this is > about the same magnitude of data. We don't currently have any > infrastructure for using ArrayBuffers for complex data, so it'd either need > to be something new (some s

Re: GamepadObserver (ie. MutationObserver + Gamepad)

On Sat, Aug 4, 2012 at 11:07 AM, b...@pettay.fi wrote: > The update rate depends on the device. Tablet updates reach way beyond >> 120HZ and even my 3D mouse clocks in at about 500 events/s. And a major >> obstacle for a realtime input device is when the realtime app trying to >> use it stutters/

Re: GamepadObserver (ie. MutationObserver + Gamepad)

On Sat, Aug 4, 2012 at 11:24 AM, Olli Pettay wrote: > It doesn't matter if they're bugs (I often see them in conjunction to >> array buffer allocation). >> > Of course it matters. APIs shouldn't be designed based on implementation > bugs It doesn't because those "bugs" have not been fixed the las

Re: GamepadObserver (ie. MutationObserver + Gamepad)

On Sat, Aug 4, 2012 at 11:31 AM, Florian Bösch wrote: > On Sat, Aug 4, 2012 at 11:24 AM, Olli Pettay wrote: > >> It doesn't matter if they're bugs (I often see them in conjunction to >>> array buffer allocation). >>> >> Of course it matters. APIs

Re: GamepadObserver (ie. MutationObserver + Gamepad)

On Sat, Aug 4, 2012 at 11:46 AM, Florian Bösch wrote: > It's OK because the other half these projects owe it to array buffers to > make things run blazing fast, since the JIT in V8 enthusiastically > optimizes JS, the reduced pointer indirection speeds things up and the > bette

Re: GamepadObserver (ie. MutationObserver + Gamepad)

On Sat, Aug 4, 2012 at 7:03 PM, Glenn Maynard wrote: > Here's a rough sketch of an API that provides clean forwards-compatibility > for devices. I think this also avoids all of the issues I talked about > earlier: it gives a clean, easy to use event-based API that preserves > ordering and timest

Re: GamepadObserver (ie. MutationObserver + Gamepad)

On Sat, Aug 4, 2012 at 7:10 PM, Florian Bösch wrote: > What happens if there is no supported profile? > Oh nm, then it's "raw", stupid question.

Re: GamepadObserver (ie. MutationObserver + Gamepad)

On Sat, Aug 4, 2012 at 7:03 PM, Glenn Maynard wrote: > I haven't tried to incorporate Florian's suggestion of using something > like ArrayBuffer. That could be supported later, eg. by providing a > readIntoBuffer(buffer) next to read(). That's too complex to try to tackle > all at once. I've h

Re: Lazy Blob

On Mon, Aug 6, 2012 at 8:39 PM, Glenn Adams wrote: > I'll leave the translation of "IM protocol" to "user facing use case" as > homework for the reader. It is trivial. My intent is to show a use case > where one would use a persistent connection and a series of send/response > messages that easil

Re: Lazy Blob

On Mon, Aug 6, 2012 at 9:33 PM, Glenn Adams wrote: > The same reason that a remote blob would be useful with XHR. > Since you're steadfastly refusing to detail your use case, that'll just mean "none" to me.

Re: GamepadObserver (ie. MutationObserver + Gamepad)

On Tue, Aug 7, 2012 at 2:29 AM, Glenn Maynard wrote: > 5ms is an *eternity* when you're aiming for 60 FPS, where you only have > 16.6ms per frame to play with. That's 30% of your CPU budget just for > memory management. It doesn't matter if it's 5ms every 100 frames, since > it's the worst case

Re: Web Components Suggestion

It's my understanding that if you want to define a strict parser using a DTD that describes the markup, it's impossible to introduce arbitrary tage names (as in there are not tag wildcards in a DTD). A document that used arbitrary tags could not be validated. On Sun, Aug 12, 2012 at 8:05 AM, Dave

Re: Web Components Suggestion

On Mon, Aug 13, 2012 at 3:12 AM, Michael[tm] Smith wrote: > There is no conceivable conformance checker that's going to allow the use > of completely arbitrary tag names. It doesn't matter what formalism it > uses. > To allow custom tag names and still be able to check the conformance of > normal

Re: Web Components Suggestion

On Mon, Aug 13, 2012 at 12:38 PM, Chaals McCathieNevile wrote: > On Mon, 13 Aug 2012 10:47:22 +0200, Florian Bösch > wrote: > > On Mon, Aug 13, 2012 at 3:12 AM, Michael[tm] Smith wrote: >> >> There is no conceivable conformance checker that's going to allow the &g

Re: Sandbox

On Mon, Sep 17, 2012 at 2:21 PM, Joran Greef wrote: > Apps (native/web) need direct access to bare metal. > > Browser vendors need to move away from the "we do all the thinking and > designing and implementing" top-down model of innovation. > > Browser vendors need to provide minimal core OS APIs

Re: Sandbox

On Mon, Sep 17, 2012 at 3:06 PM, Joran Greef wrote: > You are conflating web apps (trusted, installed) with web pages (single > link click). > You should clarify that when you say "web-apps" you mean the other kind. > No, WebSockets are not "plain old TCP". > After handshake the pipe isn't hand

Re: [pointerlock] Is Pointer Lock feature complete i.e. LC ready? [Was: Re: [admin] Publishing specs before TPAC: CfC start deadline is Oct 15]

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

Re: [pointerlock] Is Pointer Lock feature complete i.e. LC ready? [Was: Re: [admin] Publishing specs before TPAC: CfC start deadline is Oct 15]

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

Re: [pointerlock] Is Pointer Lock feature complete i.e. LC ready? [Was: Re: [admin] Publishing specs before TPAC: CfC start deadline is Oct 15]

he pointer lock request > to fail if not resulting from a user interaction target". Chrome > allows pointer lock without any user gesture if requested when in > fullscreen. Out of fullscreen a user gesture (click, key press) is > required. See > http://www.chromium.org/devel

Re: [Bug 19297] New: May user agents apply additional restrictions on entering pointer lock?

Cheer up everyone, we've got somebody dedicated to writing fullscreen exploits now :) http://feross.org/html5-fullscreen-api-attack/ Summary: Change blindness may make phishing attacks feasible (displaying a mock browser/page in fullscreen) Cause: Switch to fullscreen before user consent. Fix: Swi

Re: [Bug 19297] New: May user agents apply additional restrictions on entering pointer lock?

On Tue, Oct 9, 2012 at 11:41 AM, Charles McCathie Nevile < cha...@yandex-team.ru> wrote: > On Tue, 09 Oct 2012 08:43:13 +0200, Florian Bösch > wrote: > > Cheer up everyone, we've got somebody dedicated to writing fullscreen >> exploits now :) >> http://fero

Re: [Bug 19297] New: May user agents apply additional restrictions on entering pointer lock?

On Tue, Oct 9, 2012 at 12:41 PM, Charles McCathie Nevile < cha...@yandex-team.ru> wrote: > - What is the reasoning to switch before user consent? >>> > It allows developers to control more of the experience (which they >>> generally want). Given the price in security for the >>user, I would

Re: [Bug 19297] New: May user agents apply additional restrictions on entering pointer lock?

On Tue, Oct 9, 2012 at 1:45 PM, Anne van Kesteren wrote: > On Tue, Oct 9, 2012 at 12:51 PM, Florian Bösch wrote: > > TL;DR I don't think you lose anything of value if you move the > confirmation > > to before the fullscreen change and you might just inadvertedly promot

Re: [admin] Publishing specs before TPAC: CfC start deadline is Oct 15

I've been toying a bit with the current chrome implementation of gamepads, and been trying to make sense of how it would work for firefox. There's a few observations I'd like to share: - Being able to enumerate devices is very convenient. I don't think Firefoxes implementation went that way which

Re: full screen api

There was a limited discussion on that a few days ago with the limited consensus (?) being that requiring user-consent up front before switching to fullscreen is desired, should be in the standard and isn't sacrificing UX. On Fri, Oct 12, 2012 at 8:20 PM, Carr, Wayne wrote: > There’s a recent p

Re: Defenses against phishing via the fullscreen api (was Re: full screen api)

On Sat, Oct 13, 2012 at 1:49 PM, Maciej Stachowiak wrote: > I think the most effective defense against phishing via fullscreen is to > prevent keyboard access. The original design for requestFullscreen had an > optional argument for requesting keyboard access, which led to a warning in > some bro

Re: Defenses against phishing via the fullscreen api (was Re: full screen api)

You're making fullscreen useless for games. On Sat, Oct 13, 2012 at 9:56 PM, Maciej Stachowiak wrote: > > On Oct 13, 2012, at 4:58 AM, Florian Bösch wrote: > > On Sat, Oct 13, 2012 at 1:49 PM, Maciej Stachowiak wrote: > >> I think the most effective defense against

Re: Defenses against phishing via the fullscreen api (was Re: full screen api)

WebGL FPSes with fullscreen support - http://media.tojicode.com/q3bsp/ - https://developer.mozilla.org/en-US/demos/detail/bananabread - http://dl.dropbox.com/u/6873971/data/cube2/index.html On Sat, Oct 13, 2012 at 9:58 PM, Florian Bösch wrote: > You're making fullscreen useless f

Re: Defenses against phishing via the fullscreen api (was Re: full screen api)

On Mon, Oct 15, 2012 at 12:54 AM, Chris Pearce wrote: > I support making the spec general enough that implementors can chose their > security features based on their requirements; what's appropriate for a > desktop browser may not be appropriate for a tablet, for example. > An implementation, all

Re: Defenses against phishing via the fullscreen api (was Re: full screen api)

Ok, so here's my question. You have a webapp (that oh, happens to be a game, or a slideshow app, or a video player with controls, etc.) which needs keyboard/UI events access to work (come to think of it, can you honestly think of any sort of usecase that does work entirely without user intercation?

Re: Defenses against phishing via the fullscreen api (was Re: full screen api)

in > making a distinction between the two cases. > > Regards, > Maciej > > On Oct 15, 2012, at 3:45 AM, Florian Bösch wrote: > > Ok, so here's my question. You have a webapp (that oh, happens to be a > game, or a slideshow app, or a video player with controls, etc.) which >

Re: Defenses against phishing via the fullscreen api (was Re: full screen api)

On Tue, Oct 16, 2012 at 7:48 AM, Maciej Stachowiak wrote: > What are the cases where webpage-driven (as opposed to > browser-chrome-driven) fullscreen is really compelling, but they need full > keyboard access including alphanumeric keys? (Not saying there aren't any, > I am just not sure what th

Re: Defenses against phishing via the fullscreen api (was Re: full screen api)

On Tue, Oct 16, 2012 at 10:56 PM, Vincent Scheib wrote: > However, if other browsers only implement fullscreen without keyboard > support then clearly it would be best if developers could detect this when > composing their application interface, avoiding prompting users to enter > fullscreen if i

Re: Defenses against phishing via the fullscreen api (was Re: full screen api)

On Wed, Oct 17, 2012 at 4:51 PM, Rick Waldron wrote: > I'm not sure where this falls, but how would things like control-w or > cmd-w work? If the non-alphanumerics work, but the alphanumerics do not... > will that close the window? > Far as I understood it the "keyboard disabled" refers to keyboar

Re: Defenses against phishing via the fullscreen api (was Re: full screen api)

t. >> >> There are different approaches today, but none of them prevent the user >> from interacting with the full screen app before they've approved it going >> full screen. >> >> >-Original Message- >> >From: Jonas Sicking [mailto:jo...@

Re: Defenses against phishing via the fullscreen api (was Re: full screen api)

t keyboard, but touch events would be restricted. On Fri, Oct 19, 2012 at 4:01 AM, Florian Bösch wrote: > There are two problems with your proposal: > > 1) Apple has indicated of not being comfortable with keyboard (and/or UI?) > events in fullscreen at all. > 2) Apple has also i

Re: Defenses against phishing via the fullscreen api (was Re: full screen api)

On Fri, Oct 19, 2012 at 4:50 AM, Carr, Wayne wrote: > If touch events are restricted, how does the user pause the video? > If you do not disable click/touch on devices with an onscreen keyboard, how do you defend against phishing?

Re: Defenses against phishing via the fullscreen api (was Re: full screen api)

On Fri, Oct 19, 2012 at 9:08 AM, Feross Aboukhadijeh wrote: > "Apple has also indicated of not liking confirm prompts of any kind > whatsoever" > > To reiterate: for 90% (probably more) of fullscreen use cases, there would > be no confirmation prompt at all. Only when the developer specifically >

Re: Defenses against phishing via the fullscreen api (was Re: full screen api)

FYI Flickr slideshows and Google street view are now fullscreen users. On Tue, Oct 23, 2012 at 12:04 AM, Chris Pearce wrote: > On 16/10/12 18:48, Maciej Stachowiak wrote: > > Many games could work with only non-alphanumeric keys or in some cases > only the mouse. As could slideshows. You only n

Re: Defenses against phishing via the fullscreen api (was Re: full screen api)

On Tue, Oct 23, 2012 at 12:50 AM, Maciej Stachowiak wrote: > Based on all this, I continue to think that requesting keyboard access > should involve separate API, so that it can be feature-detected and given > different security treatment by vendors as desired. This is what Flash > does, and they

Re: Pre-fetch rough draft

The specification states that "Prefetch requests must not include cookies." which is not an effective measure to prevent user profiling. For instance somebody could auto generate the prefetch.txt tailored to the user to fetch URLs like to http://somedomain.com/whatever?userID=1358f2d55b34fb581fd547

Re: Pre-fetch rough draft

It's also a little unclear to me how prefetch improves the html manifest or how they compare. It seems as if prefetch does pretty much the same as the manifest except that it distributes fetching of the actual resources out over time that the user might not be visiting a site. Wouldn't it make more

Re: Two years on and still no sensible web storage solutions exist

I'd like to propose as a constructive strategy not to flame/offend everybody right off the bat. I'm sure there's reasons, I'd like to hear them, too. On Fri, Nov 9, 2012 at 7:24 PM, Todd Blanchard wrote: > It has been two years since the following little note was attached to the > Web SQL Spec >

Re: Two years on and still no sensible web storage solutions exist

On Mon, Nov 12, 2012 at 10:45 AM, Todd Blanchard wrote: > I've settled on using SQLite on smart phones (Android and iOS - we will > not support phones lacking this capability) and I'm going to just rely on > calls to the server for desktop apps. I think fetching from the server > will be no worse

Re: Two years on and still no sensible web storage solutions exist

On Mon, Nov 12, 2012 at 1:12 PM, Charles McCathie Nevile < cha...@yandex-team.ru> wrote: > The Webapps group will continue to try and reach industry agreement on > ways to handle data storage for offline applications. Help is appreciated. > Trying to help is generally appreciated too. > A slight t

Re: Two years on and still no sensible web storage solutions exist

On Mon, Nov 12, 2012 at 1:36 PM, Todd Blanchard wrote: > Wondering what is wrong with the blob type in SQLite? > A couple of things 1) Array buffers can't be passed to websql 2) websql is subject to the hard quota (5mb) and I'm talking about gigabytes of data 3) traditionally blobs in RDBMSes are

Re: Two years on and still no sensible web storage solutions exist

On Mon, Nov 12, 2012 at 3:49 PM, Kyle Huey wrote: > Er, IndexedDB should handle ArrayBuffers just fine. If you're seeing > problems with that that's an implementation bug, not a case that the spec > failed to handle. > You're right it does, I just checked. Nevertheless there are some issues. Th

Re: Two years on and still no sensible web storage solutions exist

On Mon, Nov 12, 2012 at 7:19 PM, Todd Blanchard wrote: > Gigabytes of data? Why would one subject WebSQL to a hard quote of 5M and > think using gigabytes of user disk space in a different scenario is OK? > Something seems out of balance here. Why limit one but not the other? > The hard quota i

Re: Two years on and still no sensible web storage solutions exist

On Mon, Nov 12, 2012 at 7:42 PM, João Eiras wrote: > You're again confusing implementation details with the specification. User > agents are free to implement whatever quota management they want, as long > as it's transparent and respects the visible effects on the webpage side. > That may be so,

Re: Two years on and still no sensible web storage solutions exist

Similarly the vendors deciding not wanting to support WebSQL isn't a spec issue and it should be filed in the bug tracker of your favorite vendor. On Mon, Nov 12, 2012 at 8:02 PM, João Eiras wrote: > On Mon, 12 Nov 2012 19:50:20 +0100, Florian Bösch > wrote: > > On Mon, Nov

Re: Two years on and still no sensible web storage solutions exist

Care to paste that one? I'll test it in firefox. On Mon, Nov 12, 2012 at 9:25 PM, Boris Zbarsky wrote: > On 11/12/12 8:17 AM, Florian Bösch wrote: > >> This testsite: >> http://codeflow.org/issues/**indexeddb.html<http://codeflow.org/issues/indexeddb.html> >>

Re: Two years on and still no sensible web storage solutions exist

In FF 16.0.2 on linux, 50mb put takes about 100ms and get takes about 500ms. On Mon, Nov 12, 2012 at 10:50 PM, Boris Zbarsky wrote: > On 11/12/12 12:31 PM, Florian Bösch wrote: > >> Care to paste that one? I'll test it in firefox. >> > > http://pasteb

Re: Two years on and still no sensible web storage solutions exist

A-ha. Filled payload with random. Now it's FF 4.4s put, 5.5s get. In line with chromes perf. On Mon, Nov 12, 2012 at 11:46 PM, Boris Zbarsky wrote: > On 11/12/12 1:56 PM, Florian Bösch wrote: > >> In FF 16.0.2 on linux, 50mb put takes about 100ms and get takes about >>

random numbers API

Motivation: Web Applications enter the arena of interactive content creation/consumption (games, productivity software, etc.). A good PRNG would be desirable in many situations. Web Applications that desire to use random numbers have a 4 problems with the existing Math.random function. 1) The imp

Re: random numbers API

On Fri, Nov 16, 2012 at 4:22 PM, Anne van Kesteren wrote: > Did you discuss this with TC39? > I did not, sorry if this is the wrong place for it.

Re: random numbers API

On Fri, Nov 16, 2012 at 4:24 PM, wrote: > The W3C Web Cryptography working group [1] has a draft that seems to > include a method to generate cryptographically random values [2]. > It does include a random number generator. However it does not include seeding and consequentially no guarantees a

Re: random numbers API

On Fri, Nov 16, 2012 at 5:20 PM, David Bruant wrote: > That'd be a nonsense to add seeding in my opinion. If you want security, > you don't want to take the risk of people seeding and loose all security > property. If it's for debugging purposes, the seeding should be part of a > devtool, not of

Re: random numbers API

I'll see that I can come up with a test suite that verifies statistical and runtime behavior of an array of algorithms implemented in JS, it'll probably take a while. On Fri, Nov 16, 2012 at 6:02 PM, David Bruant wrote: > Le 16/11/2012 17:35, Florian Bösch a écrit : > > O

Re: Defenses against phishing via the fullscreen api (was Re: full screen api)

On Thu, Dec 20, 2012 at 8:08 AM, Maciej Stachowiak wrote: > And given this difference in UA behavior, it seems useful to let web > developers feature-detect the difference in behavior somehow. > It would be useful to be able to detect it. But it's in no way cruical, we can just do if($.browser.sa

pointerLock vendor prefixes, shims and usability

The pointerlock API is currently prefixed with vendor prefixes. This is fine in principle since it is an experimental API that lacks consistency and consensus and that's what vendor prefixes are for. A vendor prefix should serve to inform a developer that he's using non-standard functionality that

Re: pointerLock vendor prefixes, shims and usability

On Mon, Dec 24, 2012 at 9:31 PM, Boris Zbarsky wrote: > That's fixed as of 3 days ago in Firefox nightlies, for what it's worth. > That's good to hear that more of this becomes shimable. > Events already allocate a new object or ten, for what it's worth. > > - vendorpointerlockchange events ca

Re: Pointer Lock status. Was: pointerLock vendor prefixes, shims and usability

I should note that I do have an application in the oven that could serve as a usecase study for non fullscreen pointerlock UX/issues (it uses pointerlock in different portions of its functionality to improve usability). It's currently not ready for release, but upon request I can arrange for a per

File Save As

I'm currently working on an Application that requires to save and open files from a users computer with a selection dialog. Opening files works fine by creating an upon user interaction, listening to the change event, triggering a click and grabbing the file. Saving files does not work as smooth

Re: File Save As

On Sat, Jan 5, 2013 at 7:42 PM, Glenn Maynard wrote: > Note that for saving dynamically-generated content to disk, you probably > want FileSaver rather than @download. With @download you have to put the > whole file in a data: URL, which doesn't scale to larger files--you wouldn't > want to put a

Re: File Save As

On Sun, Jan 6, 2013 at 1:33 AM, Boris Zbarsky wrote: > This, I agree is a problem. > The semantic used by countless applications and which is an extremely well established UX pattern is: - First "Save" -> Open Save As dialog - Subsequent "Save" -> overwrite previous location - Any "Save As" -> A

Reading image bytes to a PNG in a typed array

Having a texture in WebGL and wanting to encode it into a typed array as PNG, I have found that the only way to do it is the following convoluted method. 1) Create canvas, set to desired size 2) Create 2D context 3) Create imageData object 4) Create a WebGL framebuffer object 5) Attach texture as

Re: Reading image bytes to a PNG in a typed array

. On Mon, Jan 14, 2013 at 1:46 PM, Anne van Kesteren wrote: > On Mon, Jan 14, 2013 at 1:20 PM, Florian Bösch wrote: > > Having a texture in WebGL and wanting to encode it into a typed array as > > PNG, I have found that the only way to do it is the following convoluted > > met

Re: Reading image bytes to a PNG in a typed array

On Mon, Jan 14, 2013 at 4:00 PM, Glenn Maynard wrote: > You want toBlob, not toDataURL. > So how would I stick a blob into an arraybuffer?

Re: Reading image bytes to a PNG in a typed array

Perhaps we should think of a better scheme to export data than toFoo(). Maybe toData('url'), toData('arraybuffer') toData('blob') or perhaps toData(URL), toData(ArrayBuffer) or toData(Blob). I tend to think that if you're starting to write toA, toB, toC, toX methods on an object, you've not thought

Re: Reading image bytes to a PNG in a typed array

Whatever the eventual solution to this problem, it should be the user of the API driving the decision how to get the data. On Wed, Jan 16, 2013 at 4:56 PM, Kyle Huey wrote: > > On Wed, Jan 16, 2013 at 7:50 AM, Glenn Maynard wrote: > >> On Wed, Jan 16, 2013 at 9:40 AM, Flori

Re: Proposal: moving tests to GitHub

I think it's a good idea. The WebGL specification/tests moved to github which made contributing patches (as pull requests) a lot easier. On Tue, Jan 22, 2013 at 11:53 AM, Odin Hørthe Omdal wrote: > Hi! > > We just had a small discussion on webapps-testsuite [1] about the > possibility of movin

Re: Proposal: moving tests to GitHub

I can't guess how important the whole "attribution" thing is. I can however say that having a public repository on github makes it easier for "drive-by" contributors to contribute something. The traditional process captures almost none of these contributions. I can also tell that I (and probably mo

Re: Reading image bytes to a PNG in a typed array

mime/encoding header > 6) implement base64 decode in JS and decode to Uint8Array > > Less steps and it's now async as well. > > > > > On Wed, Jan 16, 2013 at 8:02 AM, Florian Bösch wrote: > >> Whatever the eventual solution to this problem, it should be the u

Keyboard events for accessible RIAs and Games

I have written a blog post at length about this issue here: http://codeflow.org/entries/2013/jan/30/keyboard-events-in-javascript-are-broken/ In short the problem is the following: - RIAs (shortcut systems) and Games (shortcut systems and action systems) need to be able to identify each key unique

Re: Keyboard events for accessible RIAs and Games

t the UIEvents (formerly "DOM Level 4 Events") > Editor's Draft at: > https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm > I believe that it addresses all of your concerns but I'm interested in any > comments that you might have. > > Thanks, > -Gary >

Re: Keyboard events for accessible RIAs and Games

On Wed, Jan 30, 2013 at 8:20 PM, Wez wrote: > Would a French user expect such a dialog to say "Now press > Ctrl+Shift+/+&", though? > I think that users expect shortcut mappers to show them the unmodified primary symbol of the key. For instance for a swiss guy the shortcut "ctrl+shift+ö" is expe

Re: Keyboard events for accessible RIAs and Games

e (numeric, unmodified) and then translate that to a localized display. A lot of shortcuts will make sense regardless of locality, but it's important for a user to figure out which shortcuts don't work for them by looking at the shortcut display. On Wed, Jan 30, 2013 at 8:37 PM, Florian

Re: Keyboard events for accessible RIAs and Games

On Wed, Jan 30, 2013 at 9:02 PM, Gary Kacmarcik (Кошмарчик) < gary...@chromium.org> wrote: > Yes, trying to match the current (virtual) keycap was not a direct goal, > but adding the 'code' attribute makes it possible (when combined with the > current layout) to calculate a keycap value. > I think

Re: Keyboard events for accessible RIAs and Games

What/where would be a good place to put the API for say queryKeyCap(code) ? On Wed, Jan 30, 2013 at 9:38 PM, Florian Bösch wrote: > On Wed, Jan 30, 2013 at 9:02 PM, Gary Kacmarcik (Кошмарчик) < > gary...@chromium.org> wrote: > >> Yes, trying to match the current (virt

Re: Re: Keyboard events for accessible RIAs and Games

Sounds fine to me, any objections to add it to the Event Level 4 spec? On Thu, Jan 31, 2013 at 11:46 AM, Hallvord Reiar Michaelsen Steen < hallv...@opera.com> wrote: > > What/where would be a good place to put the API for say > queryKeyCap(code) ? > Given that the implementation will have a Keyb

Allow ... centralized dialog up front

There is a problem confronting applications desiring to use a variety of APIs such as pointerlock, fullscreen, WebRTC, local storage and so on. The problem is that each instance of attempting to use such an API leads to a new "Allow ..." popup the user has to click away. By some discussion on the

Re: Re: Keyboard events for accessible RIAs and Games

with A) not doing accessible, localized, user friendly things or B) doing more user unfriendly things like popping "allow ..." dialogs all over. I have forked issue B in its own thread, hopefully so that neither A or B will be necessary. On Thu, Jan 31, 2013 at 11:57 AM, Florian Bö

Re: Allow ... centralized dialog up front

You suggest a bulk up front permission dialog doesn't work, whereas pinging the user at random intervals with a popup does? On Fri, Feb 1, 2013 at 10:12 AM, Anne van Kesteren wrote: > On Thu, Jan 31, 2013 at 2:18 PM, Florian Bösch wrote: > > I would propose to centralize this

Re: Re: Allow ... centralized dialog up front

On Fri, Feb 1, 2013 at 12:30 PM, Charles McCathie Nevile < cha...@yandex-team.ru> wrote: > That kind of bulk approach does not work. Users don't understand >>> what's going on. >>> >> > That's what research shows. To be fair, we've generally presented the > options in ways that are over-technical.

  1   2   3   >