Confirm
45
edits
Changes
→Layout Matching Algorithm
=== Layout Matching Algorithm ===
When an input field is focused, if it is not an "option", its <code>type</code> attribute will be used to filter a set of candidate layouts (if the input field doesn't provide a <code>type</code> attribute, we will use the default type, which is "text".) A candidate layout means it can handle this input type or is possible to let user input all characters that this input field accepted.
For example, if the type of a input is "url", then a layout with "url" or "text" listing on the "types" on its manifest will be matched. However, if a input field with type "text", then all layouts support "text" will be matched, but those layouts only support "url" are not. This is because we believe layouts that can handle "text" could be a fallback for "url" input type, but not vice versa. A input type fallback plan is pre-defined as follows:
* "text" is the fallback of "text", "textarea", "url", "email", "password" and "search".
* "number" is the fallback of "number", "tel"
The matching algorithm of keyboard manager in System app is as following:
# Get focused input type
# Get fallback input type
# Find out all layouts that support either focused input type or fallback input type.
After step 3, keyboard manager will sort the list and display the first layout. The sorting criteria is defined by UX or users in Settings.
== Proposed API ==
