Implied case folding with Combobox search attribute

[hsivonen]

https://open-ui.org/components/combobox.explainer/#the-search-attribute says:

Typing “a” will display “Apple”, “Apricot”, and “Banana”. definition here.

However, "Apple".includes("a") evaluates to false.

If the intent of to have more complicated processing, such as case folding, the more complicated processing should be explicit.

If case folding is to be performed, the case folding should probably be aware of Turkish and Azerbaijani being special, and a definition of where the language information is taken from would be necessary.

It seems that JavaScript doesn't have a public toLocaleFoldCase operation, but browsers have it available internally.

[hsivonen]

CC @keithamus

[dbaron]

Perhaps another relevant question here is whether typing "av" should include Ávila. (Also cc @josepharhar.)

[lukewarlow]

Perhaps another relevant question here is whether typing "av" should include Ávila.

Does that match with the existing select forward type behaviour?

[hsivonen]

Perhaps another relevant question here is whether typing "av" should include Ávila.

The Web does not have a language-aware way (in the sense that ö should not match o diacritic-insensitively in Estonian, Finnish, Icelandic, Swedish, Turkish, etc.) of doing diacritic-insensitive substring matching. (Intl.Collator provides full-string matching, but I think providing it is a misfeature.) As a collator implementor, I very much don't want the Web platform to require collators to be able to perform substring search over the 64-bit collation units and be able to correlate the result back to the input characters.

It would make sense to define a language-aware character to character mapping that removes diacritics, though. I have a perma-TODO to write this up for the Unicode Consortium. Perhaps I should actually get around to writing it.

[hsivonen]

On second thought, collator-based "starts with" and "includes" would be very easy to implement. They would just be very inefficient compared to a character-level folding away diacritics like fold case does case-insensitivity on the character level.

Also, implementing a collator-based "starts with" API is an invitation to the API users to build a very inefficient "indexOf" on top, which would then be a slipperly slope towards demand for optimizing that to a slightly less inefficient collator-based "indexOf" API, which is the part that I particularly want to avoid.

[css-meeting-bot]

The Open UI Community Group just discussed Implied case folding with Combobox search attribute.

The full IRC log of that discussion

<masonf> keithamus: Henri is worried about case folding for the search attribute.
<masonf> q+
<masonf> ...we assumed we could do sub-string match. Problem is i18n. Can do case folding, but that belies the "keep things simple" approach.
<masonf> ...we don't have these operations in JS at the moment though. Eliding diacritics also, etc.
<keithamus> masonf: I wanted to clarify - his initial post - the question is, this magic could be built into the browser but then there's no fallback in JS to do the same thing?
<jarhar> q+
<keithamus> masonf: like the proposal is not a JS thing, but the browser does the complex stuff
<keithamus> masonf: all the right diacritic elidation can be done
<masonf> dbaron: in i18n circles, there isn't a single known algorithm to use
<masonf> ...therefore don't know what to do.
<masonf> ...maybe not something known to do.
<masonf> ...there isn't a known thing.
<masonf> q+
<masonf> ...two problems. Solution in the proposal may be too naive. Just substring matching. Users probably want the complicated stuff.
<brecht_dr> q+
<masonf> ...that doesn't exist in Unicode, etc. If that's a feature we provide, we probably want a JS version also.
<masonf> dbaron: language specific. Some diacritics removed, others not removed.
<masonf> ...other extra fun case is Turkish case folding.
<masonf> ...dotted I and dotless I
<masonf> ...lowercase dotted I ... {some logic I couldn't follow - it's complicated}{
<masonf> q?
<keithamus> masonf: the only thing I would want to discuss is if we need to expose this to JS. All this logic exists today, in appearance:auto you can do type-ahead and the browser will do the best thing. I don't know if we need to specify this other than intent, it can be up to the browser to do this over time.
<keithamus> masonf: I would ask why would need to specify what needs to happen
<masonf> q?
<masonf> ack mason
<dbaron> The summary is that in Turkish and Azerbaijani the case equivalent pairs are I/ı and İ/i
<keithamus> masonf: if the browser does something which is funny in a language we then don't need to be stuck because of the spec
<keithamus> q+
<masonf> TIME CHECK
<masonf> jarhar: text Henri quoted isn't something I wrote, and it links to a specific spot which is likely where the issue lies.
<masonf> ...I'd like to not be blocked on this. If removing this attribute unblocks us, I'm great with that. Without the attribute, it means the browser is deciding what to do anyway.
<masonf> ack jarhar
<keithamus> q-
<keithamus> ack bkardell
<keithamus> ack brecht_dr
<masonf> brecht_dr: as someone in a country the size of a football with 3 languages. If I'm typing french, I'm not typing all the accents, I'm just getting close to the right thing. In belgium you don't cleanly type the accents when searching.
<masonf> ...lots of users have french keyboards, I don't. That already creates issues.