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
It seems to me that apps handle this far more consistently than websites, and even apps often don't do all that well in the smartphone (small, colour, bright, fast) to e-book (large, B&W, reflective, low-contrast, slow) transition. Even just smartphone (3--6") to tablet (8--13") shows many warts with respect to sizing and positioning.
One trend that works poorly, e.g., dark vs. light modes. Apps which insist / default to a dark-mode display, which incidentally includes tools such as keyboard apps (e.g., Hacker's Keyboard, which I use), and command-line tools (Termux), are really hard to see and use. Fortunately, both have light modes which can be toggled.
3/4
@zens
It seems to me that apps handle this far more consistently than websites, and even apps often don't do all that well in the smartphone (small, colour, bright, fast) to e-book (large, B&W, reflective, low-contrast, slow) transition. Even just smartphone (3--6") to tablet (8--13") shows many warts with respect to sizing and positioning.