Gregory's Server
@zens There are some instances, yes, in which that's defensible, but it's still really fraught territory, particularly in Web (as opposed to App) space.
If you want to provide a keyboard that is NOT standard alphanumerics, perhaps. Providing additional or unavailable functionality is defensible. Replacing existing functionality with the same but in an unfamiliar manner is NOT.
If you're simply replacing the standard keyboard with equivalent functionality, then you'd better have a really good reason for doing so. And the answer is still probably "no".
A calculator app might be an example of legitimate use. Games effectively are interfaces in many respects, and likewise.
(Implementing either as websites rather than apps is ... somewhat problematic, but that's another story.)
1/4-ish
@zens
A further challenge is that if you are providing a specific input mechanism in an environment in which display characteristics very tremendously (in size, colour rendition, persistence, contrast, position relative to the operator, etc., etc.) you'd best be taking all of that into account. Static assumptions have a strong tendency to be violated.
There's an example of this I've created myself: my "Motherfucking Website" variant tends to work extremely well on emissive colour displays from 3" to 40" --- it handles size variation well. It's not unreadable on e-ink by any means, but the variance from strict #000 on #FFF colour theme means that contrast is reduced, and I really should address that (@media queries are an option, they're cussedly unreliable).
https://codepen.io/dredmorbius/full/KpMqqB
2/4
@zens
A further challenge is that if you are providing a specific input mechanism in an environment in which display characteristics very tremendously (in size, colour rendition, persistence, contrast, position relative to the operator, etc., etc.) you'd best be taking all of that into account. Static assumptions have a strong tendency to be violated.