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

On Wed, Apr 30, 2014 at 12:54 PM, Adam Bradley <adam@drifty.com> wrote:

> 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.
>

Understood.  So does touch-action help you here (in that it lets you
control scrolling and zooming without affecting other things)?  Note that
one potential disadvantage to touch-action is that you can't have it affect
a touch sequence once it's already started (i.e. change it in response to a
touchstart).  This is intentional because it enables optimizations that
apply touch-action without blocking on JavaScript at all, but it means it's
not quite as rich as a JS-API based approach like you were suggesting.  For
most cases though this seems like the right design choice.

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 for the feedback, these all sound like important problems to solve.
 +wiltzius and bokan who are also looking at some related issues (eg.
how/when to tell you what part of the viewport is occupied by a keyboard).
 Making it possible to do everything you'd want in a native Android/iOS app
using standard web APIs is a big priority for the blink team right now -
there's just a lot of ground to cover (and standards work is slow), so
we're trying hard to prioritize effectively.


> Thanks,
> Adam
>