Continuing the discussion from Invoke emoji input:
That brings up an interesting point, though: is there a way in the current set of
input attributes to really say “don’t present input methods for these classes of character”? Like, we have type hints for overall forms of input to present, like number pads, and we have complex validation expressions to mark certain overall strings as invalid, but there’s no really good hinting mechanism for “don’t even suggest the user be allowed to type this kind of character because I’m just going to reject it” (unless that disallowed set is “everything but digits” or “non-URL/email characters”).
Sure, a UA could try breaking down
pattern to see if it can figure out what characters are contextually allowed by certain rules (although that’s going to fail for a ton of complex
pattern values), but I think it’d be better if we had full-on “whitelist” and “blacklist” attributes to explicitly opt-in or opt-out to the inputs to certain well-defined character classes/sets (which could also be expanded to having the UA / polyfill actively filter out those characters, which is buggy code I know I’ve certainly written for more than a few scenarios).
Granted, restricting the character set is frequently not the best UX (see the way GitHub handles invalid characters when creating repo names, where it just tells you what name it’s going to convert it to) - but it also frequently is the best UX for many other inputs and
contenteditable-based controls (namely, ones involving numbers).
Also also, blacklisting and whitelisting by named character classes is a more friendly alternative to validation than
pattern in terms of locale-dependent patterns (even though most locale-dependent patterns already have their own
type - which can’t be applied to