Input character class whitelisting and blacklisting

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 contenteditable).

And of course there’d have to be an advisory note in the spec and documentation for this, just as there should be for every bit of functionality that can be used to restrict input (like pointer-events: none and touch-action: none), that this is only to assist users in not inputting the described characters, and that you can never rely on UA behaviors to enforce any kind of restriction (due to the nature of client-server relationships).

Help me understand here, are you asking for lets say email class not to allow more than one @ symbol and date boxes not to allow letters?

I think this may make sense in some cases certainly however as you mentioned this feels poor UX in some cases too. Is the main rationale dependable values that only validate? As validationMessage API helps with that.

It’s really about hinting what kind of input methods the UA should present in a more granular way than just declaring the type of data, ie. saying “don’t display the ‘insert emoji’ button if you have one”, or “only display the keyboard of ASCII-safe characters”.

Ok so this is strictly further clarification of what mobiles are currently doing rather than limiting down the keys a user can press on a hardware keyboard on a desktop?

Well, I was thinking it would be helpful if desktop (and mobile) browsers implemented a soft limit on characters being input by physical keyboards, too (maybe triggering something like an :error class on the input element and/or firing an event).

Also, desktop browsers have onscreen input methods, too. There’s no reason for rules like this to not apply to non-mobile IME.

Yup that’s why I stated hardware because of all the funky devices happening. "My old IBM PCI keyboard" should perhaps be the new way of referencing it

Yeah so the validation messages and API copes with that already (somewhat, it isn’t able to be styled still - see other issue)