On Jan 30, 2012, at 08:14 , Hajime Morrita wrote: > Please let this thread know if there are any concern or objection, > otherwise I'll r+ this in this week. Also, if the author of original > proposal has any discussion around the points that Adam and Simon > raised, it would be helpful to drop it here for supporting this to > happen.
Thanks a lot for taking the time to look into this. Adam said: > One minor comment: you might want to add a security consideration to > the spec about spam issues. An unfriendly web site might spam the > vibration API and deplete the user's battery. The spec explicitly defends against unwanted vibration by killing any ongoing vibration when the page is in the hidden state (as per Page Visibility). I don't think that users are likely to stay on a page that causes their device to vibrate continuously, and if they do, since it can only be the forefront page, it's probably what they want (for whatever reason, I dare not venture ask). I sure wish that audio worked that way. If I wanted to deplete battery, that's not the first thing I'd go to. Simon wrote: > My comment was actually meant to be somewhat facetious, and intended to > reflect how arbitrary the new APIs are. Why support GamePad input, and not TV > remote control input? Why only deal with vibration on a mobile device, and > not other kinds of hardware feedback? I don't think they are good APIs. Well, we could certainly wait until we've designed the full Web SDK with APIs for everything from Toaster Grill Settings to Teledildonics Protocols, or we can try to release APIs in small increments, based simply on developers' feedback and implementers' interest, then revise them over time to take new applications into account. I guess it's partly a matter of taste, but I'm actually rather happy that we're not approaching the whole stack with a hamfistedly monolithic big bang method. FWIW, the Vibration API is actually designed specifically so as to be reusable on a Gamepad, in conjunction with the gamepad people. Oh and there is a TV remote control API; it's part of DOM 3 Events. I don't know when it was added but I recall developing a TV-based webapp that used it at least seven years ago. There are also people looking at more advanced bidirectional ways of controlling a TV and reacting to its content, e.g. http://www.bbc.co.uk/blogs/researchanddevelopment/2011/02/universal-control.shtml -- Robin Berjon - http://berjon.com/ - @robinberjon _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
