I definitely agree that KeyboardShrinksView makes a tonne more sense for apps (as opposed to webpages), and it's what we use on Android. Shame they reversed the decision (I didn't actually realize that).
One reason to keep it as a plugin is that the logic seems to be hard to get right and so needs to be tweaked frequently. Plugins let you iterate faster than if it were built-in. Still, I think we're hoping to reduce the number of plugins that we maintain as a part of the core Cordova project, since we really don't do a great job at giving them the attention that they deserve (just have a look at all the unaddressed PRs against them). One of the intended goals (at least IMO) of moving plugins to npm and npm-style-naming, is to make less distinction between "core" cordova plugins and community-maintained plugins, so that the higher-quality community-maintained plugins get more usage. Interested in what others think. On Mon, Mar 30, 2015 at 1:07 PM, Connor Pearson <cjp...@gmail.com> wrote: > Hi All, > > It's been a while since the keyboard plugin was discussed. As I understand > it, the plugin was moved to Cordova labs after iOS 7 made > KeyboardShrinksView the default behavior. Since iOS 7.1 and 8 have reversed > this decision, could we revisit this? > > I've done some work to re-enable KeyboardShrinksView for iOS > 7.0 and fix > some bugs, but is there any support for continuing to maintain this plugin? > If not, is there any way to merge the KeyboardShrinksView preference back > into cordova-ios? I think it's more commonly used and much more stable than > the HideKeyboardFormAccessoryBar preference. As a Cordova user, our app > depends on the shrink view behavior. Any thoughts? > > Thanks, > Connor >
