Re: [chromium-discuss] Additional parameters within preventDefault() for more control on what gets prevented

This all stems from developing ionicframework.com, and finding that balance 
when having the ability to scroll an element with touch/mouse events, 
bringing up the virtual keyboard, moving the input's text caret, removing 
the 300ms delay, setting an "active" css class on buttons, etc. Most of our 
code could be simplified if preventDefault wasn't preventing everything 
from happening, along with the problems of it acting differently on Android 
and iOS. The end goal is to be able to control what defaults get prevented, 
so if newer APIs would be the better route then I'd be all for it.

A virtual keyboard API would also solve many of these issues. Currently 
it's pretty difficult to bring up the keyboard with just focus() because it 
needs to come from a user interaction like touchstart (but from what I 
understand this is by design). Other valuable information would be the 
keyboard height, it's layout type (like iOS split keyboard), removing the 
"Next" and "Done" accessory buttons if you wanted, adding your own 
accessory buttons, customizing the "Enter" button text (like to Search, Go, 
Filter), events triggered on keyboard show, hide and word suggestions, and 
possibly having some more control of the keyboard's actual keypad layout. 
When comparing native mobile app development to html5, these are some of 
the areas that could help web and hybrid app developers further.

Thanks,
Adam