On 2/2/12 1:01 AM, Robin Berjon wrote: > On Feb 1, 2012, at 11:02 , Soo-Hyun Choi wrote: >> On 2/1/12 3:00 AM, Simon Fraser 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, you are right in a sense that one may like to see some form of >> unified API that can represent various hardware feedback, but I guess >> that will take ages to be finalised at the W3C's point of view. > > If you're talking about full haptic feedback support, it's not just standards > that's the bottleneck (though it would indeed take a while) but also the fact > that it's a fast-moving innovation area that doesn't seem ripe for > standardisation just yet. Also, too few devices are currently equipped with > what it takes to make this interesting.
Absolutely - that's why I have said that this patch shouldn't be questioned by the W3C's standard perspective at the particular moment. As far as I understand, Simon's original suggestion was to take these sort of APIs to W3C and come back later, which doesn't seem to be quite reasonable per the reason we discussed. > > I expect that if this becomes a feature of devices that customers come to > expect and that is commonly put to good use, then there will be an API for > it. But I wouldn't hold my breath at this point. > >> In this respect, I'd like to assume that they are not simply arbitrary >> APIs, but interesting ones that might be emerged into some other form(s) >> later as W3C elaborates the spec standards. > > Yes, and not only are they not arbitrary but they are (hopefully) made to be > sufficiently orthogonal so as to be used together properly. If you search > through (http://lists.w3.org/Archives/Public/public-device-apis/) you'll find > a few occurrences of collaboration with the Gamepad team that ensure that you > can call navigator.vibrate() to get your primary device to vibrate, but also > gamepad.vibrate() with everything working the same as soon as you have a > handle on a gamepad. > Fully agreed - I didn't particularly insist it to be integrated in a single abstract-level API that can be derived on usage basis. As you've mentioned, I agree they can be orthogonal in terms of usage/functionality, so it may not necessary at all to make them such way. The whole point I am making here is that it looks quite worthwhile to enable this vibration API in the WebKit trunk. Kind regards, Soo-Hyun _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
