It seems that a WebKit reviewer, Hajime Morrita, created another bug (https://bugs.webkit.org/show_bug.cgi?id=78085) related to this patch. As said in the bug #78085, it would be more preferred way not to access Page and PageClient directly.
The author of this bug might want to check them before asking r+. Kind regards, Soo-Hyun On Thu, Feb 2, 2012 at 03:11, Soo-Hyun Choi <[email protected]> wrote: > > > 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 [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
