controlling the UA keyboard

[Ojan Vafai]

I had a chat with Monica today about Polymer trying to create custom text input elements that don't wrap the built-in input and use contentEditable instead. The built-in input is a pile of legacy complexity that a modern app shouldn't need in principle. I'll let her expand on the details, but the short version is that she needs to be able to declare which keyboard the UA should show (e.g. the number one).

This sounded very similar to me to Apple's desire for a way of declaring which formatting commands the text field supports (e.g. bold, italic, etc). I suspect we could design something pretty minimal that we could get cross-browser support to ship that meets both needs.

Does this make sense for input team's backlog of work to do?

[Rick Byers]

This seems like something that could be in-scope for input-dev, although I don't think we have much expertise here and I'd hope we could leverage the expertise on the editing team (at least reviewing the design and some CLs).  It sounds to me like the biggest cost here is in precisely defining the API and getting consensus around it.  Ojan, do you already have context on the history of specifying input types (what has worked well with input type=, what hasn't etc.) as well as Apple's additional use cases?  It might be most useful to help scope / cost this if you quickly sketched our something you think might be reasonable.

I filed this feature request to track.  Our plates are pretty full for Q1.  Let's collect use cases (to better understand the priority / urgency).

Rick

[Rick Byers]

Sorry, here's the correct feature request link