[whatwg] unsubscribe
Re: [whatwg] Device proximity and light events
There is a discussion on the DAP WG, we like the simplicity of the proposal however there is an important feature that is missing which is ability to set the report interval and threshold. Thanks Dzung Tran -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Doug Turner Sent: Wednesday, May 09, 2012 7:31 AM To: Anne van Kesteren Cc: Jonas Sicking; wha...@whatwg.org; Scott González; JOSE MANUEL CANTERA FONSECA; Andrei Popescu; Carr, Wayne Subject: Re: [whatwg] Device proximity and light events On May 9, 2012, at 3:14 AM, Anne van Kesteren wrote: > On Wed, May 9, 2012 at 5:59 AM, Doug Turner wrote: >> Where was that discussion? > > This came up at the WebApps F2F and there was general agreement that > if we added new events adding new event handler attributes would make > sense. Was there any notes taken? > Feature detection of some kind is useful as forcing people to > do UA sniffing leads to badness. I am not arguing that it shouldn't be done. I just don't think it as important as most people. For example, even if the device is present, it may be off or not responding. In that case, you'll have a feature that tests positive and never receive any events.
Re: [whatwg] Device proximity and light events
Hello Doug, Proximity and Light is currently in the Sensor API spec at: http://dvcs.w3.org/hg/dap/raw-file/tip/sensor-api/Overview.html This spec is in process of revising. I am planning to update this in the next couple of days. Thanks Tran -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Doug Turner Sent: Friday, May 04, 2012 11:02 AM To: wha...@whatwg.org Subject: [whatwg] Device proximity and light events I have added two new events to Firefox which allow web apps to detect light and proximity changes. http://dougturner.wordpress.com/2012/03/22/device-proximity-sensor/ http://dougturner.wordpress.com/2012/03/26/device-light-sensor/ I'd like feedback and to see if there was any interest in supporting these events in other UAs. Thanks Doug
Re: [whatwg] Low Memory Event
You should try to work this type of requests through the W3C DAP WG. They are working on similar APIs. For example the System Info API at: http://dev.w3.org/2009/dap/system-info/ Regards, Dzung Tran -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Charles Pritchard Sent: Tuesday, September 28, 2010 3:53 PM To: timeless Cc: Rob Evans; whatwg@lists.whatwg.org Subject: Re: [whatwg] Low Memory Event On 9/28/10 1:35 AM, timeless wrote: > On 9/28/10, Rob Evans wrote: > >> All good points. I think as we have moved away from simple web pages and >> really start to think about applications that are coded in js, many things >> previously the exclusive domain of desktop apps are more and more desirable >> for web apps. >> > Unfortunately, moving away from simple pages introduces pain points > previously only experienced in desktop applications. Browser design > should aim to avoid exposing such pain points. > Complex apps necessarily introduce additional work. What we're seeing, is that desktop application developers are now able to use "web" APIs. >> I also think that a web page should be able to request exclusive access to >> the graphics card just like many native games do, >> Many vendors are working hard to support WebGL. I don't think "exclusive access" makes any sense, but I'm not an expert. I recommend you review Google's work in the area, as they're supporting GL through various entry points (Native Client, WebGL, and their OpenGL+DirectX layer). I don't think that this issue has much to do with my proposal. > Only an application knows what should be done when backgrounded. But > some forms of backgrounding shouldn't really be exposed to apps. I > don't want an interstitial page to recognize that I'm ignoring it -- > sadly, the future is in this direction, interactive ads which block > content views until they're dismissed. > window.onblur and window.onfocus already expose some of this. Yes, the interactive ads now on YouTube and other services are quite annoying, and I'm sure the market will respond accordingly. But that's not a standards nor security issue. > It'd be nice to know if Safari on iOS3 sends events to pages when the > user switches "away" and "back", I've assumed it just saves a picture > and reloads the page. > Safari task switching on iOS manages tabs by task switching, or reloading. I don't know if it fires onfocus/onblur, but I'm sure it has some events. WebApp developers targeting iOS may be running as an application using a web frame. The same is true for Android devs. They are always free to inject events into their web frame; was commonly done for events like "onorientationchange". > Imagine a user loads 2 html-canvas3d games. Imagine that the system > doesn't have much memory and that the user is paying for bandwidth > (I'm in .ie w/ .uk and .fi sims -- I'm roaming, it's expensive). Is > the user going to be happy with you trying to store your inactive game > in DOM/JS (which causes swapping) and then with you trying to use the > network as a storage? The right thing to do is to recognize your FPS > This sounds like something the game designer would put in their settings. Just as they currently do when allowing users to change resolution, depth, lighting, and so forth. > unreliable/unusable for non browser applications (Maemo 5). At least > on Maemo 5 the low memory events (which were at least sort of used in > Maemo 4) are effectively never delivered. The system has 256mb of ram > (128mb is vaguely available to apps) and 764mb of swap (which prevents > low memory signals from being fired until after the system swaps to > > I realize that low memory events may not be reliably received. We have functioning examples, however, of current browsers responding to low memory events. So it can happen. A programmer should not expect that they will reliably receive low memory events. The purpose is simply to expose them in cases they may happen in. Right now, I hit low memory issues in Chrome and Firefox, frequently. I'd like to throw in a little extra code to deal with that process. Aza Raskin has put forward a great proof of concept of a web browser running dozens of tabs in a manageable UI. Whether a resource constrained system, or a system that's just running a hundred different processes, allowing hooks for "onsuspend" "onlowmemory", may mean that WebApp developers will support those conditions. In the meantime, devs do code for those events, in non-standard ways, through tool kits like Phonegap > guy determine where the risk point is. Typically what has happened for > perhaps 20 or more years in desktop/web applications is that low > memory conditions lead to "code execution vulnerabilities". > Chrome does a graceful crash of some running processes and not others. It would not introduce an attack vector to notify those still-running processes with
Re: [whatwg] Do we really need to introduce a element for giving access to webcams and mikes?
The was added by Ian Hickson in response to some of the work in the W3C DAP working group. The original intent was to make sure the user are actively grant permission to a particular device camera or microphone instead of just click okay since some malicious site can just capture and post it on the internet. Here is a reference to the work in W3C DAP: http://dev.w3.org/2009/dap/camera/Overview.html Some threads on the topic: http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0248.html http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0194.html Thanks Dzung Tran, -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Julien Cayzac Sent: Monday, May 03, 2010 07:41 PM To: whatwg@lists.whatwg.org Subject: Re: [whatwg] Do we really need to introduce a element for giving access to webcams and mikes? On Tue, May 4, 2010 at 11:37 AM, Julien Cayzac wrote: > I am not sure if I get your point here: are you saying that using the > webcam locally in a canvas and somehow transmitting the webcam video > over the network are two independent permissions to grant? If so, how > would you detect the latter, since by allowing the page to manipulate > the video in you would give it permission to use toDataURL() > too, so it could still transmit frames to the server or to other party > if a ConnectionPeer is involved? To answer my own question: by raising the origin-clean flags of the element the webcam was "attached" to. Now, I see no reference to any interaction between and mentionned in http://dev.w3.org/html5/html-device/ Julien. -- Julien Cayzac http://julien.cayzac.name/ skype://jcayzac?chat
Re: [whatwg] Web API for speech recognition and synthesis
Currently the W3C Device API WG is working on a Capture API which will include microphone capture and audio streaming capabilities. The current draft is at: http://dev.w3.org/2009/dap/camera/ It is pretty rough and still in working progress, so for instance streaming is not there. Thanks Dzung Tran On Sun, Dec 13, 2009 at 6:46 PM, Ian McGraw mailto:imcg...@mit.edu>> wrote: > I'm new to this list, but as a speech-scientist and web developer, I wanted > to add my 2 cents. ?Personally, I believe the future of speech recognition > is in the cloud. > Here are two services which provide Javascript APIs for speech recognition > (and TTS) today: > http://wami.csail.mit.edu/ > http://www.research.att.com/projects/SpeechMashup/index.html > Both of these are research systems, and as such they are really just > proof-of-concepts. > That said, Wami's JSONP-like implementation allows Quizlet.com to use speech > recognition today on a relatively large scale, with just a few lines of > Javascript code: > http://quizlet.com/voicetest/415/?scatter > Since there are a lot of Google folks on this list, I recommend you talk to > Alex Gruenstein (in your speech group) who was one of the lead developers of > WAMI while at MIT. > The major limitation we found when building the system was that we had to > develop a new audio controller for every client (Java for the desktop, > custom browsers for iPhone and Android). ?It would have been much simpler if > browsers came with standard microphone capture and audio streaming > capabilities. > -Ian >
