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

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

Also concrete use case for virtual keyboard API is UI effect for smiles
which are shown instead of keyboard, like in Hangouts app. This is really
difficult to do without special API.


2014-04-30 21:10 GMT+04:00 Rick Byers <rbyers@chromium.org>:

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


-- 
@nekrtemplar <https://twitter.com/nekrtemplar>