Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Matching input to datalist values #1011
4.10.8. The datalist element
The datalist element matches user input to options in a list. In current implementations in Chrome and Firefox, as you type into a text input field the browser suggests alternatives based on the text you type. This is extremely useful for working with long lists (such as country selection), or for helping the user find list items when they don't know the beginning of the option text.
However, the string matching involved can be taken to various levels of complexity when dealing with languages besides English, especially because this is matching of natural language data, rather than identifiers.
Current implementations will match 'This' to 'this', which seems reasonable. However, the i18n WG feels that browsers should as a minimum also normalise the text being compared prior to matching. We feel that this normalisation should not be compatibility normalisation (ie. it should be NFC or NFD, but not NFKC or NFKD).
We also believe that case-insensitive matching should take into account local tailoring, eg. so that Turkish i matches İ but not I.
Beyond that, however, there are many types of comparison that could be made, including things such as accent-stripping, matching kana with kanji, matching full- and half-width characters, etc.
The i18n WG proposes that the HTML spec:
The problem here is the larger problem of "string searching" (for which we have a FPWD that we're not currently working on). This type of natural language text matching is somewhat more complex than substring or namespace name matching--including (and not limited to) case insensitivity issues. Browsers do have implementations of this kind of searching--which is not specified in HTML: it's the "find" feature.
Note that Richard wrote "matching kana with kanji", to which I would add matching katakana and hiragana (and the wide/narrow katakana equivalents should match). And to accent-stripping (the matched text), I would add respecting accepts (case-insensitively) when they form part of the user input.
[@aphillips please correct me if needed]
For the SHOULD text i think we're asking HTML to require implementers to:
Both those should be testable.
If you filed this issue and you still think it is relevant, please open a new issue on the WHATWG repository and reference this issue (if there is useful information here). Before you open a new issue, please check for existing issues on the WHATWG repository to avoid duplication.